From Fedora Project Wiki

< FWN‎ | Beats

m (add anchor)
(FWN #146 spellchecked, basic first pass)
Line 7: Line 7:
Contributing Writer: [[OisinFeeley|Oisin Feeley]]
Contributing Writer: [[OisinFeeley|Oisin Feeley]]


=== Default Deactivation of Services ===
=== PATH:/sbin Tab Confusion ===


[[ChristophHoger|Christoph Höger]] initiated[1] this week's mammoth thread with a request to disable four services currently activated by default: <code>sendmail</code>, <code>ip6tables</code>, <code>isdn</code> and <code>setroubleshootd</code>. Christoph invited the list to "go on and punish me" after supplying some brief reasons for the deactivations.
Some time ago (2008-04-23) it was proposed[1] by [[TomCallaway|Tom Callaway]] to append <code>/sbin\</code> and <code>/usr/sbin</code> to the path of non-root users. The rationale was to make it easier for non-root users to use tools which are traditionally perceived as "administration" tools, for example <code>ifconfig</code>, <code>parted</code> and <code>fdisk</code>. A good overview of the problem was posted[2] by [[BehdadEsfahbod|Behdad Esfahbod]] . An excellent compendium of objections to the proposal posted[3] by [[EnricoScholz|Enrico Scholz]] encapsulates most of the problems perceived at the time. Several prolonged discussions on the topic mostly centered[4] around alternate strategies which included moving binaries from <code>/sbin</code> to <code>/bin</code>, symlinking from one to the other directory, or setting up[5] <code>sudo</code> by default.


[1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02197.html
[1] https://www.redhat.com/archives/fedora-devel-list/2008-April/msg01625.html


Discussion mostly centered on the <code>sendmail</code> problem with suggestions ranging from starting it asynchronously and late, as suggested[2] by [[AlanCox|Alan Cox]], to replacing it with one of the "send-only" MTAs such as <code>ssmtp</code>. Part of the interest over this seemed to be stimulated by the information posted[3] by [[ColinWalters|Colin Walters]] that the "[...] desktop image no longer installs sendmail by default." This led to a need to distinguish between the desktop LiveCD and regular installs, as was done[4] by [[BillNottingham|Bill Nottingham]]. Some apparent legal threats posted by [[MatthewWoehlke|Matthew Woehlke]] led[5] [[SethVidal|Seth Vidal]] to point him to the nearest convenient exit. [[RalfErtzinger|Ralf Ertzinger]] noted[6] the deeply entrenched nature of <code>sendmail</code>: "Unfortunately, sendmail isn't just a program, it's an API. Calling /usr/lib/sendmail has been the way to get mail out (wherever out is) in UNIX for, well, as long as sendmail exists, which is quite some time."
[2] https://www.redhat.com/archives/fedora-devel-list/2008-April/msg01661.html


[2] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02410.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-April/msg01649.html


[3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02203.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-April/msg01727.html


[4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02308.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-April/msg01629.html


[5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02384.html
The case for moving many of the binaries was made[6] strongly by [[DavidCantrell|David Cantrell]] and arch-skeptic [[RalfCorsepius]] voiced[7] a general objection that "[...] this discussion is as old as */sbin exists [... and I] consider both proposals to be populist propaganda." After much thrashing out of the issue the proposal was coalesced[8] in the Feature named "/sbin Sanity" and <code>/usr/local/sbin:/usr/sbin:/sbin</code> were appended to the <code>PATH</code> of normal users of Fedora 10. A related change suggested was to allow firstboot to configure sudo to grant the first created user all privileges but this feature is not present in Fedora 10 Beta.


[6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02505.html
With the release of Fedora 10 Beta some of the predicted daily inconveniences of the change have been realized[9]. [[MattMiller|Matt Miller]] (who had been consistently opposed to the change) reported that command-line completion was cluttered with multiple unwanted choices: "We've just made the command line a lot less user friendly for common use in exchange for an ugly fix to a small inconvenience." In a wryly humorous post he noted that due to wanting <code>/etc/profile.d</code> to continue working he could not simply set a static path. [[StephenSmoogen|Stephen Smoogen]] joked[10] that Matt was the "[...] first systems administrator I have met in several years who hasn't had /usr/sbin:/sbin in their default path. You sure they didn't make you a manager and didn't tell you?" and added that "I think the chance for putting it back is still there.. if someone is willing to do the work on the hard but correct way? I think it was crickets the last couple of times when volunteers were asked for that." NigelJones was among several who asserted[11] that typing the full paths was what they preferred and Stephen admitted[12] that he had received some offlist ribbing and promised to mend his ways: "I am removing /sbin:/usr/sbin from my path and learning to type /usr/sbin for the commands I have 'shortcutted' over the years. Next I will be removing the bad habit of '/sbin/sudo bash' :)"


The problem of lack of local delivery with the proposed replacements was brought up[7] by [[PatriceDumas|Patrice Dumas]]. This was seen as a stumbling block because <code>cron</code> needs it and led [[JesseKeating|Jesse Keating]] to argue[8]: "[W]e shouldn't be using local delivery for this stuff. Instead we should ask in firstboot where you'd want the mail delivered to." [[MattMiller|Matt Miller]] replied[9] with a link to a bugzilla entry in which he had proposed just such a thing in 2004. Other aspects of the problem of disentangling potentially important log data from the mail delivery mechanism were touched[10] upon in other parts of the thread. Deep in the thread [[ArjanvandeVen|Arjan van de Ven]] pointed[11] to aliases generation as the reason for <code>sendmail</code> being slow to start up.
[6] https://www.redhat.com/archives/fedora-devel-list/2008-April/msg01732.html


[7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02246.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-April/msg01761.html


[8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02253.html
[8] http://fedoraproject.org/wiki/Features/SbinSanity


[9] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02349.html
[9] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00001.html


[10] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02411.html
[10] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00003.html


[11] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02217.html
[11] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00004.html


The complaint about <code>setroubleshootd</code> was addressed[12] by [[SteveGrubb|Steve Grubb]]. He explained that he had intended it to be a plugin to <code>audispd</code> it but had ended up being implemented as a standalone daemon by another author.
[12] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00181.html


[12] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02322.html
[[VilleSkyttä|Ville Skyttä]] and [[MatthewMiller|Matt Miller]] volunteered[13] to take up the burden of moving appropriate binaries out of <code>/sbin</code> and into <code>/bin</code> in order to help revert the change.


<code>ip6tables</code> was defended on two fronts. On the first [[DanielBerrange|Daniel P. Berrange]] explained[13] how accessible IPv6 was and how likely it was that all machines on a network could automatically acquiring IPv6 addresses. Typical of the reaction on the other front [[GregoryMaxwell|Gregory Maxwell]] was startled[14] at the idea of being exposed without firewalling upon plugging into an IPv6 enabled network. He added the statistic that "About 4% of the web browsers hitting English language Wikipedia are IPv6 enabled. IPv6 enabled web clients may even become more numerous than Linux desktops this year, almost certainly by next year, so be careful what you call rare. :)" [[StephenSmoogen|Stephen John Smoogen]] also explained[15] that if there were no IPv6 firewall a <code>ping6 -I eth0 ff02::1</code> would enable an attacker to "walk the hosts with no firewalls." He suggested that completely disabling IPv6 would be preferable but might affect <code>IPsec</code> and related components.
[13] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00003.html


[13] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02286.html
Over on @fedora-desktop [[RahulSundaram|Rahul Sundaram]] suggested a <code>kickstart</code> snippet which would add the first user to the wheel group and add blanket permissions to the wheel group in <code>/etc/sudoers</code> . [[ColinWalters|Colin Walters]] agreed[14] with the concept but wondered "[a]re we too far into the F10 process for this?"


[14] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02271.html
[14] https://www.redhat.com/archives/fedora-desktop-list/2008-October/msg00006.html


[15] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02206.html
=== Speeding-up Modprobe and MAKEDEV ===


No one seemed particularly concerned at the idea of disabling <code>isdn</code> by default as it explicitly requires further configuration to be useful.
Inspired by [[ArjanvandeVen|Arjan van de Ven's]] five-second Asus EeePC boot and Mandriva's work on similar topics [[JakubJelinek|Jakub Jelinek]] posted[1] his patches to improve the speed of <code>modprobe</code> and <code>MAKEDEV</code>. He hoped that this sharing would result in more community experimentation. The first patch enables <code>depmod -a</code> to produce compact binary files which can be searched for aliases and dependencies more quickly than the standard text files, which are still also produced. The patch to <code>MAKEDEV</code> similarly reduces the size of the searched files, in this case config files, and improves the efficiency of an inner loop. The times appeared to be decreased by several orders of magnitude according to the sample figures posted by Jakub.


=== specspo and PackageKit ===
[1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00043.html


A quick query was posted[16] by [[RichardHughes|Richard Hughes]] asking whether <code>PackageKit</code> should dump its dependency on <code>specspo</code>[17]. The advantage would be a savings of 27Mb installed size and 6.9Mb download size. [[TimLauridsen|Tim Lauridsen]] was against a hard dependency and argued[18] that as <code>specspo</code> was part of the @base group it would be installed by default on a normal desktop and could then be used, whereas on the LiveCD its absence was desired due to the space constraints.
[[KyleMcMartin|Kyle McMartin]] was excited[2] and suggested that "[t]he biggest win by far for <code>MAKEDEV</code> is profiling the often hit devices, and prioritizing things. Dave Airlie moved a bunch of the cciss and other almost never-seen devices to be sourced last and ended up with a huge win." [[BillNottingham|Bill Nottingham]] responded[3] that <code>MAKEDEV</code> ought not to be run at boot at all. [[JakubJelinek|Jakub Jelinek]] was not optimistic that the <code>MAKEDEV</code> patch would be applied upstream as he noted[4] that he had sent it upstream over ten months ago.


[16] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02026.html
[2] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00046.html


[17] "specspo" is the rpm package which contains all the portable object catalogues which provide translations for Fedora packages.
[3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00047.html


[18] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02034.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00054.html


An interesting discussion about alternate methods to provide translated package descriptions ensued when [[SethVidal|Seth Vidal]] suggested[19] that instead of using <code>specspo</code> "translating pkgs might best be served by translating the metadata in external files." In response to [[BillNottingham|Bill Nottingham's]] skepticism that this was just moving bloat to a new location Seth explained[20] that it would allow only the data specific to the requested language to be fetched. In a further explanation he provided[21] an overview of the ideal mechanism which would allow translations only for the language in use to be installed. This involved <code>yum</code> downloading translations from a language-segmented repodata and inserting those translations into the local <code>rpmdb</code>. A further reason to find an alternative to <code>specspo</code> was advanced[22] by [[StepanKaspal|Stepan Kaspal]] when he drew attention to its lack of friendliness to third-party repositories: "the specspo solution is not extensible at all; if you add a third part repository, the messages just are not there. And the repository cannot install another catalogue, rpm uses just 'the catalogue'."


[19] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02058.html
=== Uniform Proxy Settings ===


[20] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02125.html
The issue of constructing a uniform method of enforcing proxy settings for applications was raised[1] by [[KulbirSaini|Kulbir Saini]]. He complained "[w]henever I try a new version of Fedora, the first problem I face is setting the proxy. It seems for almost every application, I have to specify proxy at a different place."


[21] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02164.html
[1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00097.html
A reply by [[SimonAndrews|Simon Andrews]] recapped[2] previous debates on the topic by pointing out the twin problems of a lack of a common setting and the inability of many applications to update their proxy settings on the fly. Simon suggested that a localhost proxy could be forced on all applications if <code>NetworkManager</code> were to contain hooks to re-route local proxy requests either directly to the internet or via a secondary proxy. He admitted "this all feels a bit icky to me - but I can't think of a nicer way of doing this which doesn't require the cooperation of the authors of every proxy-aware application."


[22] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02160.html
[2] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00159.html


[[BillNottingham|Bill Nottingham's]] objections seemed[23] to involve both the resource intensiveness of doing this during the composition of the repodata and also that "[...] this is all stuff that exists."
[[NicolasChauvet|Nicolas 'kwizart' Chauvet]] had also thought about the problem and made[3] some changes to <code>libproxy</code> which he hoped would solve the problem. [[DanWinship|Dan Winship]] wrote[4] a great post explaining that <code>libproxy</code> could adaptively use whichever backend was appropriate for the environment in which it was used and although it was not widely used by applications it looked set to become an integral part of GNOME.


[23] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02165.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00098.html


=== Are Other Distros Controlling Fedora through PackageKit ? ===
[4] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00185.html


A thread initiated[24] by [[ThorstenLeemhuis|Thorsten Leemhuis]] explored some details on how information on packages is created and stored at the distribution level and the challenges this presents both to independent repositories and to tools which wish to use this data. One heated aspect of this discussion concerned the manner in which the <code>PackageKit</code>[25] application installer defines and presents groupings of packages. <code>PackageKit</code> is designed to be a distribution-independent tool and it appeared to some in the discussion that its direction was inimical to the best release-engineering practices of the Fedora Project. The central issue appeared to be that <code>PackageKit</code> developers were not spending time helping to refine the <code>comps.xml</code> file which defines how packages are bundled during installation and is used by every other tool.
After [[ColinWalters|Colin Walters]] commented[5] that he would like to "[...] see the desktop standardize around <code>libsoup</code>[6] , for two primary reasons: 1) Mainloop integration 2) Hopefully forthcoming support for reading Firefox cookies [...]" a minor flamewar erupted when [[JamesAntill|James Antill]] wondered "Why do "desktop people" keep proposing things that are _only_ acceptable in a monolithic desktop application?" with reference to the mainloop integration. This developed into a comparison[7] between future scenarios in which PackageKit overrode yum downloads in a desktop scenario versus the simplicity of using yum on the command line. James was scathing on the subject of ignoring actual users (whom he asserted prefer gnome-terminal) to "[...] 60+ year olds who don't, and are about to be a majority of our users RSN."


[24] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01813.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00188.html


[25] http://packagekit.org/pk-intro.html
[6] libsoup is a GNOME client/server library for HTTP used in evolution, seahorse and rhythmbox among others and is integral to the OnlineDesktop.


Thorsten asked a series of questions about the correct use of <code>comps.xml</code> and how it interacted with <code>anaconda</code>, <code>PackageKit</code> and <code>yum</code>. Thorsten was concerned that there appeared to be 1711 packages missing from <code>comps.xml</code> in order that "[...] people can find and select them right during install with anaconda. Do we care?"
[7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00201.html


After some investigation with the latest <code>PackageKit</code>, which [[RahulSundaram|Rahul Sundaram]] pointed out[26] uses <code>comps.xml</code>, Thorsten deduced[27] in discussion with [[TimLauridsen|Tim Lauridsen]] that "[...] adding packages to a group in comps.xml as '<packagereq type="optional">' is only worth the trouble if you want to make the package selectable in anaconda, as that information is not used by pk-application." [[TimLauridsen|Tim Lauridsen]] explained[28] that <code>PackageKit</code> used the comps.xml groups as "meta-packages" but [[JamesAntill|James Antill]] disagreed[29] that they were similar.
=== Fedora 10 Early Branch Now Available ===


[26] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01819.html
[[JesseKeating|Jesse Keating]] announced[1] on 2008-10-01 that it was now possible for developers wishing to concentrate on stabilization to branch their packages. A link to request a branch was provided. In response to [[JeroenvanMeuwen|Jeroen van Meuewen]] it was explained[2] that this was not mass-early-branching but was an attempt to satisfy two classes of maintainers: those that needed to continue future development and those that used the entire development cycle for the current release.


[27] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01861.html
[1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00083.html


[28] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01859.html
[2] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00126.html


[29] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01889.html
MichaelSchwendt rejected[3] the idea as "[u]nconvincing and not helpful", citing increased bureaucracy as the main negative outcome and suggesting that a potential cascade of maintainers scrambling to branch and rebuild in response to early branches of dependencies would result.


[[AlexLancaster|Alex Lancaster]] agreed[30] with Thorsten's concern that many packagers were not using comps.xml and posted a link that showed that both he and [[ToshioKuratomi|Toshio Kuratomi]] had been thinking about using <code>PackageDB</code> to generate <code>comps.xml</code> for some time[31].
[3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00202.html


[30] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01893.html
=== SELinux - Copying ISO Files ===


[31] See also http://fedoraproject.org/wiki/FWN/Issue136#Application.Installer..22Amber.22.Provides.Browser.Interface.to.Packages and http://fedoraproject.org/wiki/FWN/Issue82#Presto.Server.Back.Up...Interesting..25doc.Behaviour..Presto.Now.in.Extras.21
A paraliptic swipe at SELinux by [[JonMasters|Jon Masters]] asked[1] "[...] how is the *average* user supposed to [...] copy the content of /mnt over to e.g. /somewhere/fedora/9/i386 for NFS installs [?]" [[DanWalsh|Dan Walsh]] was surprised[2] and responded "Why would the copy fail? cp should just work and set the files to the context of the destination directory. If this fails it is a bug." Jon conceded[3] that there was a bug and segued into a mini-rant on SELinux.


In sustained discussion with [[KevinKofler|Kevin Kofler]] a defense of <code>PackageKit</code> was mounted[32] by [[RichardHughes|Richard Hughes]] using the argument that it was intended to be a compliment to <code>yum</code> rather than a replacement. Its intent is to occupy a very narrow niche for the specific type of user identified by "profiles" produced by the PackageKit developers.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00140.html


[32] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02015.html
[2] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00154.html


[[JamesAntill|James Antill]] had done[33] some investigation of the difference between how PackageKit and <code>yum</code> presented groups of packages and was not impressed: "In short it's arbitrarily different, hardcoded and just plain wrong. But hey, you've done "substantial user research" while we're just lowly developers, so feel free to keep ignoring us."
[3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00203.html


[33] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02008.html
[[JesseKeating|Jesse Keating]] offered[4]: "The average user double clicks on the iso in Nautilus, which mounts it for them. Then they click/drag the fileset to where they want it and Nautilus copies it for them."


The evolution of <code>comps.xml</code> to its current complexity was advanced[34] by [[NicolasMailhot|Nicolas Mailhot]] as the result of multiple constraints of engineering, maintenance and legality, he argued that "[i]t's always easy to present one-shot specialized solutions. The difficulty is scaling because separate maintenance of specialized overlapping package collections is not efficient). When you refuse to look at scaling problems you're missing the core of the problem."
[4] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00174.html
 
[34] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02089.html
 
When it seemed that <code>PackageKit</code> was being designed[35] to take the needs of other distributions into account and that this might have a negative effect on Fedora there was a great deal of disapprobation expressed[36] by [[JesseKeating|Jesse Keating]]: "If I'd known that upstream was actively looking to destroy our package classifications, rather than actually work with us to clean them up a bit maybe I would have joined the conversation. A heads up might have been in order. I fear that any conversation now will just be too little too late." [[MatthiasClasen|Matthias Clasen]] characterized[37] this as Jesse being more interested in confrontation than making things better but [[NicolasMailhot|Nicolas Mailhot]] also saw[38] the decisions being made about <code>PackageKit</code>'s design as "non-representative" of developers focused on Fedora. Interestingly he tied this in with an observation on "[...] desktop team mislike for the common distro communication channel [.]" A slight rapprochement seemed[39] to be in effect towards the end of the thread as tempers cooled.
 
[35] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01957.html
 
[36] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01974.html
 
[37] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01976.html
 
[38] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02012.html
 
[39] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02022.html
 
The issue of binary packages (several of which can be produced from any single source package) was attacked when [[ToshioKuratomi|Toshio Kuratomi]] listed[40] <code>PackageDB</code>, <code>amber</code>, <code>koji</code>,<code>comps.xml</code>, <code>repoview</code> and <code>Fedora collection</code> as all "[...] doing a subset of the work in this area." He asked for some clarity as to the storage, interface and presentation layers. [[KevinFenzi|Kevin Fenzi]] agreed but added[41] <code>mash</code> as another player and suggested that perhaps all the developers of the respective systems could meet to hash out some agreed plan. [[JesseKeating|Jesse Keating]] confirmed[42] Kevin's description and elaborated: "it's mash that pulls comps out of cvs and 'makes' it and uses it when generating repodata. Mash is used during rawhide production and during update repo generation. When we make releases, that uses pungi which consumes the comps data that mash generated and merges in data from any other repo pungi is configured to use. Then pungi calls repoview to create data based on that merged comps."
 
[40] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01949.html
 
[41] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02182.html
 
[42] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02185.html
 
=== /sbin and /bin Linked to /usr/lib ===
 
[[SteveGrubb|Steve Grubb]] posted[43] the output from a utility which he had authored to check whether applications in the <code>/bin</code> and <code>/sbin</code> directories link against anything in the <code>/usr</code> directory. In the ensuing discussion [[BillCrawford|Bill Crawford]] suggested[44] that one of the listed applications, <code>/bin/rpm</code> was useful in its present location because of the "[...](admittedly quite odd situations) where you need to, say, reinstall grub or a kernel because you broke something[.]" He added that a "rescue" <code>initrd</code> would help for machines without optical drives.
 
[43] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02315.html
 
[44] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02458.html

Revision as of 00:20, 5 October 2008

Developments

In this section the people, personalities and debates on the @fedora-devel mailing list are summarized.

Contributing Writer: Oisin Feeley

PATH:/sbin Tab Confusion

Some time ago (2008-04-23) it was proposed[1] by Tom Callaway to append /sbin\ and /usr/sbin to the path of non-root users. The rationale was to make it easier for non-root users to use tools which are traditionally perceived as "administration" tools, for example ifconfig, parted and fdisk. A good overview of the problem was posted[2] by Behdad Esfahbod . An excellent compendium of objections to the proposal posted[3] by Enrico Scholz encapsulates most of the problems perceived at the time. Several prolonged discussions on the topic mostly centered[4] around alternate strategies which included moving binaries from /sbin to /bin, symlinking from one to the other directory, or setting up[5] sudo by default.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-April/msg01625.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-April/msg01661.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-April/msg01649.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-April/msg01727.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-April/msg01629.html

The case for moving many of the binaries was made[6] strongly by David Cantrell and arch-skeptic RalfCorsepius voiced[7] a general objection that "[...] this discussion is as old as */sbin exists [... and I] consider both proposals to be populist propaganda." After much thrashing out of the issue the proposal was coalesced[8] in the Feature named "/sbin Sanity" and /usr/local/sbin:/usr/sbin:/sbin were appended to the PATH of normal users of Fedora 10. A related change suggested was to allow firstboot to configure sudo to grant the first created user all privileges but this feature is not present in Fedora 10 Beta.

With the release of Fedora 10 Beta some of the predicted daily inconveniences of the change have been realized[9]. Matt Miller (who had been consistently opposed to the change) reported that command-line completion was cluttered with multiple unwanted choices: "We've just made the command line a lot less user friendly for common use in exchange for an ugly fix to a small inconvenience." In a wryly humorous post he noted that due to wanting /etc/profile.d to continue working he could not simply set a static path. Stephen Smoogen joked[10] that Matt was the "[...] first systems administrator I have met in several years who hasn't had /usr/sbin:/sbin in their default path. You sure they didn't make you a manager and didn't tell you?" and added that "I think the chance for putting it back is still there.. if someone is willing to do the work on the hard but correct way? I think it was crickets the last couple of times when volunteers were asked for that." NigelJones was among several who asserted[11] that typing the full paths was what they preferred and Stephen admitted[12] that he had received some offlist ribbing and promised to mend his ways: "I am removing /sbin:/usr/sbin from my path and learning to type /usr/sbin for the commands I have 'shortcutted' over the years. Next I will be removing the bad habit of '/sbin/sudo bash' :)"

[6] https://www.redhat.com/archives/fedora-devel-list/2008-April/msg01732.html

[7] https://www.redhat.com/archives/fedora-devel-list/2008-April/msg01761.html

[8] http://fedoraproject.org/wiki/Features/SbinSanity

[9] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00001.html

[10] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00003.html

[11] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00004.html

[12] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00181.html

Ville Skyttä and Matt Miller volunteered[13] to take up the burden of moving appropriate binaries out of /sbin and into /bin in order to help revert the change.

[13] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00003.html

Over on @fedora-desktop Rahul Sundaram suggested a kickstart snippet which would add the first user to the wheel group and add blanket permissions to the wheel group in /etc/sudoers . Colin Walters agreed[14] with the concept but wondered "[a]re we too far into the F10 process for this?"

[14] https://www.redhat.com/archives/fedora-desktop-list/2008-October/msg00006.html

Speeding-up Modprobe and MAKEDEV

Inspired by Arjan van de Ven's five-second Asus EeePC boot and Mandriva's work on similar topics Jakub Jelinek posted[1] his patches to improve the speed of modprobe and MAKEDEV. He hoped that this sharing would result in more community experimentation. The first patch enables depmod -a to produce compact binary files which can be searched for aliases and dependencies more quickly than the standard text files, which are still also produced. The patch to MAKEDEV similarly reduces the size of the searched files, in this case config files, and improves the efficiency of an inner loop. The times appeared to be decreased by several orders of magnitude according to the sample figures posted by Jakub.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00043.html

Kyle McMartin was excited[2] and suggested that "[t]he biggest win by far for MAKEDEV is profiling the often hit devices, and prioritizing things. Dave Airlie moved a bunch of the cciss and other almost never-seen devices to be sourced last and ended up with a huge win." Bill Nottingham responded[3] that MAKEDEV ought not to be run at boot at all. Jakub Jelinek was not optimistic that the MAKEDEV patch would be applied upstream as he noted[4] that he had sent it upstream over ten months ago.

[2] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00046.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00047.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00054.html


Uniform Proxy Settings

The issue of constructing a uniform method of enforcing proxy settings for applications was raised[1] by Kulbir Saini. He complained "[w]henever I try a new version of Fedora, the first problem I face is setting the proxy. It seems for almost every application, I have to specify proxy at a different place."

[1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00097.html

A reply by Simon Andrews recapped[2] previous debates on the topic by pointing out the twin problems of a lack of a common setting and the inability of many applications to update their proxy settings on the fly. Simon suggested that a localhost proxy could be forced on all applications if NetworkManager were to contain hooks to re-route local proxy requests either directly to the internet or via a secondary proxy. He admitted "this all feels a bit icky to me - but I can't think of a nicer way of doing this which doesn't require the cooperation of the authors of every proxy-aware application."

[2] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00159.html

Nicolas 'kwizart' Chauvet had also thought about the problem and made[3] some changes to libproxy which he hoped would solve the problem. Dan Winship wrote[4] a great post explaining that libproxy could adaptively use whichever backend was appropriate for the environment in which it was used and although it was not widely used by applications it looked set to become an integral part of GNOME.

[3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00098.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00185.html

After Colin Walters commented[5] that he would like to "[...] see the desktop standardize around libsoup[6] , for two primary reasons: 1) Mainloop integration 2) Hopefully forthcoming support for reading Firefox cookies [...]" a minor flamewar erupted when James Antill wondered "Why do "desktop people" keep proposing things that are _only_ acceptable in a monolithic desktop application?" with reference to the mainloop integration. This developed into a comparison[7] between future scenarios in which PackageKit overrode yum downloads in a desktop scenario versus the simplicity of using yum on the command line. James was scathing on the subject of ignoring actual users (whom he asserted prefer gnome-terminal) to "[...] 60+ year olds who don't, and are about to be a majority of our users RSN."

[5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00188.html

[6] libsoup is a GNOME client/server library for HTTP used in evolution, seahorse and rhythmbox among others and is integral to the OnlineDesktop.

[7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00201.html

Fedora 10 Early Branch Now Available

Jesse Keating announced[1] on 2008-10-01 that it was now possible for developers wishing to concentrate on stabilization to branch their packages. A link to request a branch was provided. In response to Jeroen van Meuewen it was explained[2] that this was not mass-early-branching but was an attempt to satisfy two classes of maintainers: those that needed to continue future development and those that used the entire development cycle for the current release.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00083.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00126.html

MichaelSchwendt rejected[3] the idea as "[u]nconvincing and not helpful", citing increased bureaucracy as the main negative outcome and suggesting that a potential cascade of maintainers scrambling to branch and rebuild in response to early branches of dependencies would result.

[3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00202.html

SELinux - Copying ISO Files

A paraliptic swipe at SELinux by Jon Masters asked[1] "[...] how is the *average* user supposed to [...] copy the content of /mnt over to e.g. /somewhere/fedora/9/i386 for NFS installs [?]" Dan Walsh was surprised[2] and responded "Why would the copy fail? cp should just work and set the files to the context of the destination directory. If this fails it is a bug." Jon conceded[3] that there was a bug and segued into a mini-rant on SELinux.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00140.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00154.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00203.html

Jesse Keating offered[4]: "The average user double clicks on the iso in Nautilus, which mounts it for them. Then they click/drag the fileset to where they want it and Nautilus copies it for them."

[4] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00174.html

Retrieved from "https://fedoraproject.org/w/index.php?title=FWN/Beats/Developments&oldid=53483"