Re: F22 System Wide Change: Systemd Package Split
On Fri, Jan 23, 2015 at 7:27 AM, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Jan 23, 2015 at 04:41:53AM +, Peter Robinson wrote: >> I agree on the systemd-filesystem side of things, the binaries sounds >> like it would be better described as systemd-utils with a provides for >> -units. > This could be a good idea, but I think that having an additional > name would cause more confusion. The name is arbitrary anyway. Sure, put all the interesting tools in a -utils rpm. Oh, wait, we already have that, it is called systemd.rpm. :) I really do not want to see this broken package-split being implemented. The core systemd is not supposed to be separated into different packages. Things have complex inter-dependencies, they change all the time and they move around. Splitting them will just create a mess, for no apparent reason than optimizing some misguided space-saving efforts. We really have more important problems to solve than making the already far to complex package management even worse, and without any obvious benefit. Please just drop the entire proposal. Thanks, Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Systemd Package Split
On Wed, Jan 21, 2015 at 12:21 PM, Jaroslav Reznik wrote: > = Proposed System Wide Change: Systemd Package Split = > https://fedoraproject.org/wiki/Changes/SystemdPackageSplit > > Change owner(s): Zbigniew Jędrzejewski-Szmek > > Split systemd-units out of the main systemd package > > == Detailed Description == > Systemd contains many binaries and depends on a fairly large number of > libraries. Packages which carry systemd units currently have to depend on > systemd (through %post, %preun, %postun macros used to install and uninstall > systemd units), which grows the dependency tree and increases the size of > minimal installs. > > With this proposal systemd-units subpackages will be split out again: > systemd-units > > This subpackage will contain the directories and binaries necessary to satisfy > %post, %preun, %postun macros for packages containing systemd units > (systemctl, systemd-escape, systemd-sysusers, udevadm, journalctl), and config > information (pkg-config files). > > The main systemd package would require this package so it will be pulled in on > all existing systems. All packages which have BuildRequires:systemd will also > pull it in transitively. > > Systemd previously had a -units subpackage and ~150 packages still depend on > it. Those packages would start using the reduced subpackage immediately. Other > packages wishing to use the reduced dependency, would have to change the > BuildRequires and Requires to systemd-units. We have been there, we merged it back for many reasons, and do not want to go back. This all sounds like a really bad idea and has no support from my side. Systemd binaries, unit files and RPM macros are not supposed to live in separate packages, they are one entity and should live in one package. If you want to play such weird package installation games, the only sensible option I currently see, would be to create an empty, zero-file-content systemd-filesystem.rpm which only owns the directories for other stuff to put things into. Randomly splitting active parts which belong together into different packages makes no sense at all. Please just drop this proposal as it is. It creates more problems that it is supposed to solve. Thanks, Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
On Mon, May 5, 2014 at 9:52 PM, Reindl Harald wrote: > Am 05.05.2014 21:45, schrieb Kay Sievers: >> On Mon, May 5, 2014 at 6:15 PM, Matthew Miller >> wrote: >> >>> And calling /usr/libexec "Fedora-only" is of course kind of >>> funny. >> >> "libexec" is Fedora-only, no other major distro used it, not even LSB >> allowed it. > you systemd-guys are really funny - /run was okay and FHS did > not matter because it don't get often enough updates and was in > your way, libexec is not OK because you don't like itand prefer > to fix things which ain't broken - wheter it's part of a proposed > FHS update and from where it comes It is not about being funny, it is about making reasonable decisions. /run solved a huge old problem, libexec is pointless and only creates needless and nothing but annoying differences. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
On Mon, May 5, 2014 at 6:15 PM, Matthew Miller wrote: > And calling /usr/libexec "Fedora-only" is of course kind of > funny. "libexec" is Fedora-only, no other major distro used it, not even LSB allowed it. It makes no sense to ever have that, and the rest of the world realized that long ago. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary of accepted Fedora 21 Changes - weeks 13/14
On Tue, Apr 8, 2014 at 10:35 AM, Petr Pisar wrote: > On 2014-04-07, Lennart Poettering wrote: >> On Mon, 07.04.14 15:00, Jaroslav Reznik (jrez...@redhat.com) wrote: >>> * PrivateDevices=yes and PrivateNetwork=yes For Long-Running Services >>> URL: >>> https://fedoraproject.org/wiki/Changes/PrivateDevicesAndPrivateNetwork >>> Announcement: >>> https://lists.fedoraproject.org/pipermail/devel/2014-March/197175.html >>> > [...] >> To answer this: the kernel network namespace thing PrivateNetwork= is >> built on disconnects all address families at once. There's no choice to >> only disassociate some address families, either all or none. (except for >> the weirdness of AF_UNIX sockets in the fs namespace which stay >> connectable as long as the fs is reachable, see feature page). >> > What about D-Bus? D-Bus uses AF_UNIX currently. But as you can know, > there is an aim to move D-Bus to a new protocol family. Is it possible that > all the daemons with a D-Bus control interface will stop work then? If you mean kdbus, it is not related to network, it is based on character devices. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: cloud images and journald/rsyslog
On Wed, Jul 17, 2013 at 7:54 PM, Miloslav Trmač wrote: > rsyslog has facilities to read from journal, send the full data in > text, receive and read it back, and even write it back to journal at > the destination. (Full disclosure I haven't actually tried such a > chain up, and I wouldn't be surprised if there were some differences > between this and just copying the journal binary logs.) "External" (already logged) data passed to the journal again will record the time stamps of the copying not the ones from the original source. Most of the data would be there, but it would be something different. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: About volatile udev directory
On Fri, May 24, 2013 at 11:23 AM, Michal Schmidt wrote: > On 05/23/2013 11:46 AM, Sergio Belkin wrote: >> >> I've found the following in Fedora 18 >> [root@mpinode02 sergio]# LANG=C ls /run/udev/rules.d >> ls: cannot access /run/udev/rules.d: No such file or directory >> >> I haven't found anything in the changelog about a change about it, is >> there no more that directory ? > > In F17 dracut created the directory from the initramfs's "init" script. In > F18 dracut does not use this script anymore, as the initramfs is based on > systemd. > > I do not know if something else is supposed to create the directory. Let's > ask Kay. It is not created by default. The one who needs it can create it. Cheers, Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Wed, Mar 6, 2013 at 5:28 PM, wrote:
>> -Original Message-
>> From: devel-boun...@lists.fedoraproject.org [mailto:devel-
>> boun...@lists.fedoraproject.org] On Behalf Of Michal Schmidt
>> Sent: Tuesday, March 05, 2013 10:22 PM
>> To: devel@lists.fedoraproject.org
>> Subject: Re: Proposed F19 Feature: systemd/udev Predictable Network
>> Interface Names
>>
>> On 03/04/2013 04:01 PM, Matt Domsch wrote:
>> > drivers/net/ethernet/sfc/siena.c: efx->net_dev->dev_id =
>> EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1;
>>
>> I think sfc does not really *need* to set dev_id.
>> Yes, these are multi-port cards, but the ports are on distinct PCI functions.
>>
>
> I think setting of 'dev_id' by drivers/devices used in enterprise server
> environment will be beneficial, not just for devices in which multiple ports
> share a single PCI d/b/d/f("1 PCI d/b/d/f -> 2 ports"), also for multiport
> devices with "1 PCI d/b/d/f -> 1 Port" mapping. The following scenarios
> demonstrate the requirement/usefulness -
>
> 1. As the dev_id would indicate the physical port number used by a netdevice
> and will be available to user space via sysfs, tools such as NetworkManager
> could use the information to implement intelligent/smarter bonding of
> netdevices. For example, when bonding netdevices coming from NIC partitions
> (or SR-IOV VFs) which use the same physical port, in fault tolerance mode for
> example, NM could inform the user that the netdevices being enslaved map
> to/use the same physical port and bonding them may not have desired effect.
> Dev_id would provide such information in a generic way.
>
> 2. biosdevname could possibly use 'dev_id' to determine the part of
> pp eliminating the need to determine/enumerate port number as
> pointed out here.
Using dev_id in the kernel for static and predictable per-device
properties is fine, sure.
Using dev_id with per-driver-global internal counters, or anything
else that depends on any sort of probing or loading order is not; the
range of dev_id must be local to every "instance" than can be
separated and which the driver handles.
Otherwise, I would not be surprised if the "creativity" of people
would introduce new artificial and unpredictable enumerations in the
kernel with that facility. :)
Kay
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Tue, Mar 5, 2013 at 5:52 PM, Michal Schmidt wrote: > On 03/04/2013 04:01 PM, Matt Domsch wrote: >> >> drivers/net/ethernet/sfc/siena.c: efx->net_dev->dev_id = >> EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1; > > > I think sfc does not really *need* to set dev_id. > Yes, these are multi-port cards, but the ports are on distinct PCI > functions. Which actually means they should leave it alone then, and not do anything. The dev_id stuff is really not to be used across different parent devices. If there is any order unpredictable probing order enumeration logic involved in the driver spanning multiple parents, using dev_id will actually break things and not help anything. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Mon, Mar 4, 2013 at 6:01 PM, Andy Gospodarek wrote: > On Mon, Mar 04, 2013 at 10:19:14AM -0600, Matt Domsch wrote: >> > > drivers/net/ethernet/mellanox/mlx4/en_netdev.c: dev->dev_id = port - 1; >> > > drivers/net/ethernet/sfc/siena.c: efx->net_dev->dev_id = >> > > EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1; >> > > >> > > of these, both the mlx4 and siena drivers set them starting at 0. I >> > > think the fec driver might be doing so as well, but it's not as >> > > obvious. I'm pretty sure cxgb4 starts numbering at 1 just from >> > > reading the code. So, as-is in the 3.9rc1 kernel, I wouldn't be >> > > comfortable relying on the value of dev_id. >> > >> > I agree it looks like some cleanup is needed due to the inconsistency. >> > >> > This is still only an issue when a single function supports multiple >> > ethernet devices, right? >> >> I believe so, yes. > > Ok, good. I did like your idea to possibly set this to something other > than 0 in the default case and then make sure that any driver that needs > to set it can do so. The udev code just appends the dev_id number to the device name if dev_id is > 0, so either starting at 0 or at 1 would work fine and produce reliable results. Starting at 1 would create slightly more consistent names, where all names of one and the same card follow the same scheme, and 0 is not special because it is suppressed. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Mon, Feb 25, 2013 at 6:02 PM, Andy Gospodarek wrote: >> > I'd like to see kernel driver work to be sure every multi-port driver >> > with the same PCI b/d/b/f sets dev_id. That isn't necessarily true >> > today, which makes it hard to trust. biosdevname needs this too, >> > until such a time as it's dead. >> Do we have a list of these, or is it a matter of doing a driver audit? >> CC'ing gospo. > Right now almost no drivers actually set dev_id. In fact mlx4_en, > cxgb4, and sfc seem to be the only ones right now. If we feel like this > a requirement there will be work on the kernel side to add this. This only matters if there are multiple devices created by a driver for one and the same pci device. Like when we have only one entry in lspci, but multiple interfaces of the same type having this one device as a parent. Is this really common? I would expect this is a very rare exception. Thanks, Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how reload udev rules and systemd on F18
On Wed, Feb 13, 2013 at 6:29 PM, Sérgio Basto wrote: > Hi, OK but we don't have any command to trigger only /dev/vboxusb/* ? You are not supposed to trigger changes for hardware on the running system, *ever*. Package scripts are package scripts, not magic system administration tools. Special device nodes which are not interesting for anything else, and it is absolutely guaranteed that there is no current user at this moment, can be triggered that way, check: --sysname-match= in the udev man page. Everything else is not ok to touch. >> > the actual scriptlet: >> > # Assign USB devices >> > if /sbin/udevadm control --reload-rules >/dev/null 2>&1 >> >> Redundant. > > what you mean by redundant ? if I not reboot system, do I need > --reload-rules on F16+ ? (when install the package ) > and when the package is remove, how I clean it up ? (without reboot) Udev finds that out on its own, has done that in the past and still does that. >> > then >> >/sbin/udevadm trigger --subsystem-match=usb --action=add >/dev/null >> >> Not OK. > > I know, but if we don't have other solution I will keep it. Please remove it. You are doing *packaging* not system *administration*. All currently running hardware is taboo for package scripts to even look at it. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Tue, Feb 12, 2013 at 4:44 PM, Matt Domsch wrote:
> I am concerned about the naming convention at installtime. The
> current proposal removes biosdevname from comps @core as mandatory,
> and I presume would also remove it from the anaconda install
> environment as well. This leaves the kernel default naming scheme,
> which we agree is poor.
The default scheme is always the udev names, if they are not
explicitly disabled. Everything else would be customization. We can
add whatever is needed here to help specific requirements.
>> These SR-IOV show up with their own PCI function number in the kernel
>> and they are unique that way. From my point of view this is good
>> enough and we don't need to do anything here. If people want "pretty"
>> names they should provide custom and meaningful names on their own.
>> Udev does not want to establish any cross-device relations for naming,
>> and only look at the single device it is currently handling.
>
> I disagree that users should provide their own "pretty" names, when we
> do have all the information we need about these devices to provide
> "pretty" names by default ourselves. By the same argument, I don't
> need anything more from systemd/udevd now than I've had for years with
> 70-persistent-net.rules files.
Well, we cannot have everything, we either have somewhat fragile
pretty names composed by several sources and properties, spanning
multiple devices, and the overall system state. Or we have the "ugly"
but reliable and predictable names, which are a single device only.
Udev can only do the "ugly" version of the names, but the deal fits
better what we do for other subsystems, and is like "100 times"
simpler than what is required to do the pretty names. And reliability,
predictability, simplicity is actually what we looking for. We just
leave the pretty part to custom configuration.
> There are very good reasons to, in the device name, identify the
> separate (to the kernel) devices that represent the same physical
> cable jack. Dell's engineers have been adding code to the bonding
> driver to recognize when someone is bonding two kernel devices that
> share a single physical cable jack, as that's not usually the intended
> configuration. With the growing set of "applicance distributions"
> that auto-configure bonding across all visible network devices, this
> is even more important.
Sure, but custom config can add custom config for the used names too.
Having tools magically coming up with device names based on other
custom config is really nothing we ever would want to do. As soon as
custom config is in the game, there is really no need to try to be
smart, the tools that create the base config can create that config
along with it.
> The biosdevname convention of using _{1234} to identify such
> sub-devices is mirrored in your convention of appending f{1234}.
> Which works until you get to single PCI b/d/f devices with multiple
> ports (e.g. Mellanox adapters), after which you need further
> information to disambiguate the network devices. The biosdevname
> maintainers are trying to tackle this right now.
This really sounds like the wrong layer of fixing the issue.
If Mellanox adapters create multiple interfaces per parent device, the
kernel driver should set the "dev_id" of the devices, which is an
index per instance to distinguish the devices. Udev will automatically
appended the dev_id to the device name as u1,u2,... and all the names
will be unique again. We already used dev_id for the persistent net
rules in old udev revisions.
This should work all fine without any further logic, as long as the
kernel driver do the right thing here. Inventing new numbers by
checking sibling devices should be avoided here too.
Thanks,
Kay
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Thu, Feb 7, 2013 at 7:12 AM, Matt Domsch wrote: >We >will need a method to enable/disable on a per-vendor basis as we >added to RHEL in the udev rules that invoke (or don't) biosdevname. >The suggestion of linking in (or not) rules files won't work for a >distro-wide per-vendor configuration. Udev rules are installed in /usr/lib and can be "masked" by creating empty files in /etc with the same file name. That way entire rules files can be enabled/disabled, if needed. If needed, we could add a kernel command line option to the rules too. > C) There are several cases that biosdevname handles that udev doesn't >(yet) - NPAR and SR-IOV at least. These are widely used in Dell >and other vendors' servers. These SR-IOV show up with their own PCI function number in the kernel and they are unique that way. From my point of view this is good enough and we don't need to do anything here. If people want "pretty" names they should provide custom and meaningful names on their own. Udev does not want to establish any cross-device relations for naming, and only look at the single device it is currently handling. > D) the udev scheme will run out of characters in IFNAMSIZ (you've got >at most 15 chars to work with, Sure, it's an unfortunate kernel limitation we have to live with. We just do not rename anything if the name we composed does not fit. It's not really a problem, more an exotic corner case that can be covered/fixed by custom config if it really happens. >really less 5 because decimal-based >VLAN tagging is allowed, hence MAC-based won't fit). VLANS do not need to be named with their number in the network device name, they are created by custom config and not by detected hardware, so the naming problem can be solved at that level too, instead of the hardware-centric view udev has. For now, all VLANs are ignored by udev. >Once you >allow NPAR/SR-IOV you need at least 4 characters there (e.g. i254 >as suffix), leaving you with 6 usable. As mentioned above, the SR-IOV devices just get their PCI topology or slot name, not the name of the parent device, and therefore they do not run into the too long names. >You take 2 to define the >interface type (en,wl,ww), leaving 4 to describe the PCI topology. >Not gonna fit... It fits, if we don't do the "pretty name" thing biosdevname does. >And last time I looked, we can't make IFNAMESIZ >bigger, as it's kernel ABI to userspace and used in a ton of >places. Yeah, we cannot change that fact. > This is why the biosdevname naming convention is not as >pretty as yours Well, the biosdevname names are surely prettier than the udev ones. But the udev ones are predictable and have only one device to look at, when the name is composed. There is zero other logic, that would involve any global view of the system, or look at sibling devices; hence the uglier, but more robust names. >there simply isn't enough space in IFNAMSIZ to do >much given the claims already on the space that we can't ignore. >"We can't solve that, so we won't" is not acceptable. Real people >use these network features every day. The compromise of biosdevname to make pretty names, like using shorter numbers, or use the parent device as the basename for related devices, are done at the cost of general reliability and dependence of crawling the entire device tree to get a system overview, and make assumptions based on the existence of other devices. We liked the names biosdevname did, and wanted to do the same, but udev just cannot do that, it is too fragile in hotplug setups to look at anything but the device that is currently handled. > E) In this thread, it has come up several times that biosdevname falls >back to an emumeration method in some cases where the BIOS >information is not present. Yes, it does, though there are command >line flags that can disable that in general (e.g. --smbios26 means >it won't trigger unless the info is present in firmware). Well, as always, defaults matter, not options in tools. And the defaults of biosdevname did that guessing thing, which does not sound right. >As I've >handed of maintenance of biosdevname to a whole engineering team, I >don't know the current state of any other enumeration codepaths, >but I agree, that's a lousy way to get the "right" answer, and I'm >sure the engineering team would take suggestions on how to fix it, >rather than 'throw out the baby with the bathwater'. I think userspace enumeration as a general concept to start with cannot work on today's systems. With a few exceptions, no device naming should ever look at other devices for its own name, it's a model that will break in many weird ways. > F) "sane" (to a programmer) PCI bus topology is getting more and more > difficult to come by, as multiple PCI roots now hang off specific > CPUs. It will not be unusual for embedded dev
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Thu, Feb 7, 2013 at 11:36 PM, Glen Turner wrote: > On 29/01/13 05:32, Lennart Poettering wrote: > >> We figured in this it's better to just stick to a single name for each >> iface, pick a good default scheme for it, and support alternative >> schemes. > > The whole point of biosdevname was to move from a ennumeration-centric > view or a bus-centric view of network interfaces to a user-centric view > -- where possible the interface name matched the name stamped on the > chassis. Many rackable systems have two or four ethernet interfaces in > essentially random order on the chassis, so moving away from the > bus-centric names to the user-visible names was a win. > > I don't understand why, having learned this lesson, we are moving from > ennumeration-centric names to bus-centric names, even where the system > itself has told us what the interface name actually is. If the firmware provides proper names (index numbers) for the devices, udev will use these names instead of the topology-based names. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Thu, Feb 7, 2013 at 12:07 PM, Bradley Baetz wrote: > On 07/02/13 00:33, Michal Schmidt wrote: >> >> On 02/05/2013 02:53 AM, Scott Schmit wrote: >>> >>> Is there a program/script we can run that would tell us what the >>> interface names would be without biosdevname (without running the new >>> version of systemd on the box)? >> >> >> If you have Fedora 18 with updates applied your systemd is new enough to >> allow you to see the udev-generated names using: >> >> udevadm info --export -p /sys/class/net/$IFACE | grep ID_NET >> >> Example output: >> >> E: ID_NET_NAME_MAC=enx000f53014229 >> E: ID_NET_NAME_PATH=enp40s0f1d1 >> E: ID_NET_NAME_SLOT=ens4f1d1 > > > What happens with USB network devices that are plugged into different slots? > Currently my iPhone shows up as eth1, but using the above, depending on > which of two adjacent ports I happen to plug it into, I get: > > $ udevadm info --export -p /sys/class/net/eth1 | grep ID_NET > E: ID_NET_NAME_MAC=enx0226b08178a9 > E: ID_NET_NAME_PATH=enp0s29f7u1c4i2 > > $ udevadm info --export -p /sys/class/net/eth1 | grep ID_NET > E: ID_NET_NAME_MAC=enx0226b08178a9 > E: ID_NET_NAME_PATH=enp0s29f7u2c4i2 > > Will those be treated as two separate devices under this scheme depending on > which USB port I happen to use? Yes, the name will change, depending on the port used. But not randomly like eth1 names, where any other device connected before could also be be eth1. > And if so, will that actually matter? It doesn't with non-legacy tools. Tools that can talk to phones usually knows how to find the device without relying on a name. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Thu, Jan 31, 2013 at 2:45 PM, Scott Schmit wrote: > Current: > em1 -> enp2s0 That is expected, and actually the right thing to do. Udev cannot apply such "it looks like it is embedded" heuristics for very practical technical reasons. There is no reliable information about that on the system, so this logic will break sooner or later. There is also no sane way to share the namespace with the embedded interface indices defined by the firmware. It should never have been done by biosdevname that way. > em2 -> eno1 > em3 -> eno2 Ouch, is that really the case? If that's what you see on your box, then biosdevname would have "invented" its own numbers for the *fixed* SMBIOS provided index numbers, and rebased them to something different. That would be really weird. Thanks, Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Wed, Jan 30, 2013 at 12:19 PM, Gerd Hoffmann wrote: > On 01/30/13 11:55, Kay Sievers wrote: > Hi, > >>> Still looks pointless. >>> >>> You convert the old-format into new-format, then compile new-format into >>> the database. It's not obvious why you don't go straight from >>> old-format to the database. hwdata package updates would directly show >>> up in the database then, without having to touch systemd. >> >> It's as pointless as shipping a parser for a foreign and irrelevant >> format in the hwdb code. > > You need the parser anyway, for converting the old format into the new, > don't you? Right, but only in the build process, or the packaging. It's a dumb perl script. Doing it in shipped tools on the host has much higher requirements. :) >> And it is as pointless as adding weird code and ./configure stuff >> again to udev to find these files in the place of the month, where >> some distro poeple decided again where to put it, and every distro in >> a different place, with different names or file types. > > That is a bit nasty indeed. Yeah, it was a mess. Some even only shipped the .gz versions of it. >> And it is as pointless as inventing magic rules in the hwdb to >> overwrite the old files with possibly new data shipped in the new >> format. > > You could use "import $format $file" syntax in the new format, then > plumb a file with a single import line instead of the converted file > into the directory. You get the same ordering then. That could work, yeah. If we wanted to make it a "swiss army knife", which brings-in a whole bunch of other problems, and people's creativity, which we intentionally wanted to leave out here. :) Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Wed, Jan 30, 2013 at 11:42 AM, Gerd Hoffmann wrote: > On 01/30/13 01:08, Kay Sievers wrote: >> On Tue, Jan 29, 2013 at 11:13 PM, Bill Nottingham wrote: >>> Kay Sievers (k...@vrfy.org) said: >>>>> Realistically, it's new textual files, replacing old textual files, which >>>>> are then compiled into a binary file. I'm not sure why there's the >>>>> intermediate step of a second textual format, but there is. >>>> >>>> Because the original text file is a hack and a format specific to the >>>> PCI/USB IDs, and makes no sense at all for a generic hwdb. >>> >>> pci:v0010* >>> ID_VENDOR_FROM_DATABASE=Allied Telesis, Inc >>> >>> It's not like that's that much more of a generic format. :) >> >> It is entirely generic. It can carry arbitrary numbers of freely named >> key/value pairs basically unlimited in their size. Is extensible, uses >> flexible and extensible string matches like modaliases for kernel >> modules. Nothing you would find in the PCI/USB IDs hack. >> >> So what do you criticize here? > > Still looks pointless. > > You convert the old-format into new-format, then compile new-format into > the database. It's not obvious why you don't go straight from > old-format to the database. hwdata package updates would directly show > up in the database then, without having to touch systemd. It's as pointless as shipping a parser for a foreign and irrelevant format in the hwdb code. And it is as pointless as adding weird code and ./configure stuff again to udev to find these files in the place of the month, where some distro poeple decided again where to put it, and every distro in a different place, with different names or file types. And it is as pointless as inventing magic rules in the hwdb to overwrite the old files with possibly new data shipped in the new format. We don't want to pointlessly do any of that. Also, the textual strings are just one, and not the interesting part of the hwdb, and all should be uniform and not pull in some not convincing legacy formats, or weird rules how things are located and overwritten. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Tue, Jan 29, 2013 at 11:13 PM, Bill Nottingham wrote: > Kay Sievers (k...@vrfy.org) said: >> > Realistically, it's new textual files, replacing old textual files, which >> > are then compiled into a binary file. I'm not sure why there's the >> > intermediate step of a second textual format, but there is. >> >> Because the original text file is a hack and a format specific to the >> PCI/USB IDs, and makes no sense at all for a generic hwdb. > > pci:v0010* > ID_VENDOR_FROM_DATABASE=Allied Telesis, Inc > > It's not like that's that much more of a generic format. :) It is entirely generic. It can carry arbitrary numbers of freely named key/value pairs basically unlimited in their size. Is extensible, uses flexible and extensible string matches like modaliases for kernel modules. Nothing you would find in the PCI/USB IDs hack. So what do you criticize here? >> >> It could go into another package when things have settled down, but >> >> there will be lots of other data in the same database shipped by >> >> systemd itself, like keymaps, power settings whitelists, which we >> >> cannot really and should not move out to a generic package. >> > >> > ... which, again, is not something you want to be updating the main >> > systemd package all the time for. >> >> Which, again, is not needed at all, as mentioned above. :) > > Is it strictly needed? No. > > Is it needlessly making the problem worse? Yes. Worse? If we want an update package, it can drop the files in the same directory the default files are, and they will be used instead. Oh, and there are more copies of the PCI+USB IDs files in individual packages already, just run: find /usr -name pci.ids Maybe we should care about them first. :) > Either you're intending for the lifetime of your OS to be shipping systemd > updates that update the base data set, I don't intend to ship update packages in the context of systemd, we can just update the data in the package like we add patches for other fixes, in case we need an update. In the end PCI+USB IDs are just pretty boring names for humans, not used in the system itself. What makes them so special? It really sounds more like cosmetic care, than a real technical need to update these more often than we will need to update systemd anyway. > or you're intending to be shipping > updated data sets in a separate package. We can just do that, but still could ship the default data in the main package. > Given systemd's churn rate, the > first seems impractical, and if you're doing the second Hmm, check how often hwdata was updated, vs. systemd was updated :) http://pkgs.fedoraproject.org/cgit/hwdata.git/tree/hwdata.spec#n40 http://pkgs.fedoraproject.org/cgit/systemd.git/tree/systemd.spec#n730 > why not split it out to begin with? (Much like the preset files.) Because preset files are for spins, and not generally useful static data. They should be provided by the people doing a spin, but all spins run on the same hardware. :) And because we are not there yet, with introducing rather fragile inter-package dependencies; things should have settled down before we do this. It's all still under development. And because a major part of the data the hwdb will carry in the future will be the equivalent of udev rules, and should not be shipped by a different package, because it it might carry specifics needed for a certain functionality, just like the udev rules do today. If we want to artificially declare the PCI+USB IDs different from the rest of the growing hwdb data, and split that into a different package and the rest not; sure, we can do that when things have stabilized, but so far I'm not really sure if that will give is a significant advantage, considering that updates just can be installed along with the default data. Thanks, Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re:
On Tue, Jan 29, 2013 at 11:23 PM, Bill Nottingham wrote: > G.Wolfe Woodbury (redwo...@gmail.com) said: >> > The kernel nowadays comes with built-in support for the vast majority of >> > all common storage hardware anyway, because AHCI is pretty universally >> > established. Outside of servers non-AHCI controllers practically don't >> > exist anymore. >> >> This is simply not true. >> >> There are hundreds of thousands of older desktops that are not >> technically servers that have lots of older interfaces. >> >> To say that non-AHCI controllers don't matter is to place a dignificant >> barrier to use or adoption of Linux or Fedora. > > AHCI dates to before when RHEL 5 was released in 2007. We also build > in ATA_PIIX, which covers a large number of generations before that. > > Does hardware exist that's not covered by this? Of course. However, > I'd also bet that those installing Fedora on that hardware are those > that are capable of rebuilding an initramfs if they move an existing > system to such hardware. Right, the common hardware we should cover very well, even with a host-only initramfs. People who are able shuffle disks from one hardware to the other will be able to create a generic initramfs, either before moving things around, or with the rescue system on the new one. We still do not encode any disk location/property/serial number/path into the initramfs, and we will be able to find the disks/rootfs, even when we move the disk(s) around. Because people mentioned that: none of that was true for Windows, which is very picky about any topology or driver change regarding the disk. A simple port change or haredware reconfiguration on Windows often rendered the disk unbootable, even on the same machine. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Tue, Jan 29, 2013 at 9:06 PM, Bill Nottingham wrote: > Kay Sievers (k...@vrfy.org) said: >> The hwdb is drop-in directory based, which means: >> - additionally installed data overwrites shipped data >> - stuff with the same file name in /etc/ disables stuff in /usr/lib/ >> >> Users can just install update packages, or add their own files, which >> will not conflict with the default shipped data. > > That's really not what we need, though - we have standing requests > in That Other OS for regular updates of the hardware database as used > by the tools, and having to spin systemd for this is way overkill. Sure, create an RPM with non-conflicting files that are in /etc, or sort numerically *after* the default files. >> > 1) Duplicates the data. >> > 1a) Will the two databases be kept in sync? How will that happen? >> >> No. In the long run the old textual files will no longer be used. It >> was a really bad idea from the start to parse several megabytes of >> ever-growing text files for every query submitted; it was showing up >> as CPU spikes in all sort of profiles. That model of implementing >> low-level operating system tools should just not be continued in the >> future. The systemd hwdb data can be queried almost for free. > > Realistically, it's new textual files, replacing old textual files, which > are then compiled into a binary file. I'm not sure why there's the > intermediate step of a second textual format, but there is. Because the original text file is a hack and a format specific to the PCI/USB IDs, and makes no sense at all for a generic hwdb. >> > 2) Breaks the hwdata-vs-code separation that was created earlier. >> > What were the reasons of the separation, and why are they no longer >> > applicable now? >> >> It's just not needed because of the /usr/lib/ etc/ and drop-in >> directory overwrite logic, that works for all other default vs. >> custom/update settings. > > That method implies the administrator wants to do the update without > touching the code - what we have now is the *distributor* wants to > do the update without touching the code. And for that case, packaging > it seperately is simpler. Sure, there can be am any update packages as one wants, it will all work without any conflict with the original files. >> It could go into another package when things have settled down, but >> there will be lots of other data in the same database shipped by >> systemd itself, like keymaps, power settings whitelists, which we >> cannot really and should not move out to a generic package. > > ... which, again, is not something you want to be updating the main > systemd package all the time for. Which, again, is not needed at all, as mentioned above. :) Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Tue, Jan 29, 2013 at 8:07 PM, Miloslav Trmač wrote: > On Sun, Jan 27, 2013 at 2:54 PM, Jaroslav Reznik wrote: >> = Features/SystemdHardwareDatabase = >> https://fedoraproject.org/wiki/Features/SystemdHardwareDatabase >> >> Feature owner(s): Kay Sievers >> >> The udevd service has a long history of managing kernel devices. Besides >> generating events when devices are discovered or removed it maintains a >> dynamic, stateless database of all available devices including meta data >> about >> them. With Fedora 19 we want to substantially enhance the metadata that udev >> keeps for each device, by augmenting it from a userspace database of non- >> essential information, that is indexed by device identification data such as >> PCI/USB vendor/product IDs. > > Some years ago all hardware data was moved out of various separate > packages into the "hwdata" package (even if it meant moving it out of > the original upstream source). The feature page doesn't even mention > the hwdata package. AFAICS this The hwdb is drop-in directory based, which means: - additionally installed data overwrites shipped data - stuff with the same file name in /etc/ disables stuff in /usr/lib/ Users can just install update packages, or add their own files, which will not conflict with the default shipped data. > 1) Duplicates the data. > 1a) Will the two databases be kept in sync? How will that happen? No. In the long run the old textual files will no longer be used. It was a really bad idea from the start to parse several megabytes of ever-growing text files for every query submitted; it was showing up as CPU spikes in all sort of profiles. That model of implementing low-level operating system tools should just not be continued in the future. The systemd hwdb data can be queried almost for free. > 1b) What is the long-term goal? Will one of the two go away? If > so, how and when? Phase out hwdata, as soon as things have stabilized enough, the remaining users have been converted, and people get used to the new data source. > 2) Breaks the hwdata-vs-code separation that was created earlier. > What were the reasons of the separation, and why are they no longer > applicable now? It's just not needed because of the /usr/lib/ etc/ and drop-in directory overwrite logic, that works for all other default vs. custom/update settings. It could go into another package when things have settled down, but there will be lots of other data in the same database shipped by systemd itself, like keymaps, power settings whitelists, which we cannot really and should not move out to a generic package. So all that theoretic code vs. data separation will not really mean much in the end, the hwdb will be much more than what hwdata was. It will take over quite a lot of what udev rules do today, and these should live in the main package. We will see, I think it's too early at the moment to introduce rather needless packaging complexities and dependencies for something that is still under development. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how reload udev rules and systemd on F18
On Sat, Jan 26, 2013 at 6:14 AM, Sérgio Basto wrote:
> how I should do the old command udevadm: control --reload-rules ?
> is correct : systemctl restart udev.service ?
> I don't find any in documentation that guarantee this .
>
> BTW in F18: udev.service change the name to systemd-udevd.service.
> So put in package spec, is this correct way ?
>
> %if 0%{?fedora} < 18
> systemctl restart udev.service
> systemctl restart udev-trigger.service
> systemctl restart udev-settle.service
> %else
> systemctl restart systemd-udevd.service
> systemctl restart systemd-udev-trigger.service
> systemctl restart systemd-udev-settle.service
> %endif
Please get rid of all of that, none of it is necessary, udev will
notice that on its own.
It is completely wrong to ever do that and to restart udev or other
essential sevices from packages. No package besides udev itself is
allowed to do restart these services.
Thanks,
Kay
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Thu, Jan 24, 2013 at 8:57 PM, Bill Nottingham wrote: > Matthew Miller (mat...@fedoraproject.org) said: >> > But I guess we simply have a different definition of a user here. Your >> > definition is probably closer to what the page calls "admins", which is >> > covered by the next lines in the feature page, which you didn't paste: >> >> Right. For Fedora, developers and admins are an important subset of users. >> >> > "As biosdevname is installed by default ... most administrators won't >> > see this either. " >> >> If the new scheme really is better, we should suck it up and make the whole >> change. It'd be better to do what we can to make that transition easier -- >> like using similar names were possible -- than to have a weird mixed state. > > So, thinking - if we were to go this route, I think we'd want a clean > break, where we don't use biosdevname at all if we're using this. It's maybe a bit painful but might be the least confusing option. Ugh, that thing really seems to accelerate itself quite a bit. :) > The simplest way to do that would be: > - change biosdevname to not be installed by default > - enable these rules only on install, not on upgrade > both of which are pretty easily doable. > > To quote the documentation, of the device name formats: > > * Two character prefixes based on the type of interface: > * en -- ethernet > * wl -- wlan > * ww -- wwan > * > * Type of names: > * o -- on-board device index number > * s[f][d] -- hotplug slot index number > * x-- MAC address > * ps[f][d] -- PCI geographical location > * ps[f][u][..][c][i] > * -- USB port number chain > > What concerns would people have with this naming? Off the top of my head: > > - wwan devices aren't always discoverable (they can show up as ethernet) Yeah, it's not about discovery from userspace, we will not try that. It is directly exported by the kernel, the original name of that device was already wwan0. The kernel has netdev type names it exports like "wlan", "vlan", "wwan". They are visible in sysfs, there is no logic really in userspace. > - devices that biosdevname considers emX via enumeration/guessing would > now have enpXsY, which could be considered 'uglier' Yeah, it's based on PCI IRQ table heurisitcs biosdevname does, with looking at bus == 0, and it starts counting at 1 all the devices there. We don't want to do that, and reserve the "onboard" names to actual real firmware records, and not base it on guesses. It's probably reasobably safe what biosdevname does in most cases, but we better do not get into that business and keep the safe, but granted, ugly name. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Thu, Jan 24, 2013 at 3:46 AM, Orion Poplawski wrote: > On 01/23/2013 05:29 PM, Kay Sievers wrote: >> >> What udev does here is the only sensible thing to do, if there is no >> authoritative information from the firmware about that, we don't make >> assumptions, we use the reasonable stable PCI geography. Guessing >> around which might the "human" slot number should be avoided for many >> reasons. > > > FWIW - I did a BIOS upgrade and reconfig on one of our machines and the PCI > slot numbers as shown in lscpi changed for our SATA controllers. Caused a > bit of panic when we ended up pulling the wrong drive. Yeah, we see that from time to time, sometimes even just by re-configuring things, not only on firmware upgrades. > Perhaps the BIOS > assisted names would have been more stable in this case for the ethernet > names, I don't know. It should, yes. Firmware provided index/slot/interface numbers seem to work pretty well so far. > I'm not trying to disparage this work, it seems reasonable (although I've > been bitten by a lot of crappy software assuming network devices are named > eth#, but it's able to be turned off, so meh). Right, it's a pain. Some software likes the eth* names to find the MAC address to use that as a machine-id. But all that already happens with biosdevname, and the reported issues seems pretty rare these days. > Just passing along a data > point. YMMV and all that. Thank you. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Thu, Jan 24, 2013 at 1:07 AM, John Reiser wrote: > On 01/23/2013 02:49 PM, Kay Sievers wrote: > >> Just looking at 'lspci' will in most >> cases tell you what the name of the network interface will be. > > This is not true for my machines, which I built using main boards > from ASUS, MSI, etc. It certainly is true for every PCI based machine. The default names are strictly what you see in lspci. It's decimal instead of hex, maybe that's what you missed? > The port numbers listed by 'lspci' (thus part of > the default udev name) do NOT correspond to slot numbers in any simple way. They do, just that they are the PCI geography, not the slot number in the sense of the physical slot number you see printed on your board. What udev does here is the only sensible thing to do, if there is no authoritative information from the firmware about that, we don't make assumptions, we use the reasonable stable PCI geography. Guessing around which might the "human" slot number should be avoided for many reasons. > Therefore the udev name requires translation in order to find > the right cable. This is not good. If your firmware supports on-board interfaces, or you use properly firmware-supported PCI hotplug slots, udev names will use exactly these "pretty" numbers, not the "ugly" geographical ones. You can even recognize these firmware supported numbers in the udev names, because they use a different prefix. > biosdevname has the advantage that I can determine the mapping > between cable and interface name by looking at the back of the > machine (where the cables plug in) Udev provides exactly the same without the "guessing" part. If the firmware does not provide authoritative information, udev always uses the geography, which is the safest (granted not the prettiest) thing to do. > and counting slots first, then jacks per slot. Anything that *counts* on its own, ever, is doomed to fail in the context of stable name creation. It is in the end not much better than the kernel that just *counted* ethX upwards. The very idea of counting here is the main flaw that lead to the decision that we cannot use the biosdevname scheme in udev. It just cannot work, because you introduce inter-device dependencies, which are not predictable regarding re-configuration. Udev strictly only uses information of the one and single device it handles, never of any of its siblings, because that is where the problem starts, and which cannot be solved in the end. > biosdevname has handled the mapping between > physical slot and logical PCI port. Sure, and udev does the same, if the firmware supports it. But biosdevname went too far if the firmware lacked the information, and it "invented" new numbers, based on fragile heuristics and internal counters -- things which we should strictly avoid. Thanks, Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Wed, Jan 23, 2013 at 10:54 PM, Bill Nottingham wrote: > Matthew Miller (mat...@fedoraproject.org) said: >> On Wed, Jan 23, 2013 at 07:59:07PM +, Jaroslav Reznik wrote: >> > The udevd service has a long history of providing predicatable names for >> > block devices and others. For Fedora 19 we'd like to provide the same for >> > network interfaces, following a similar naming scheme, but only as >> > fallback if not other solution such as biosdevname is installed or the >> > administrator manually defined network interface names via udev rules or >> > the old network scripts. >> [...] >> > This feature is about enabling this as default in Fedora, but only as a >> > fallback if the user/administrator did not manually assign names to >> > interfaces >> > via udev rules, or via the old networking scripts, or if biosdevname is >> > installed. >> >> This seems to invent yet another new naming scheme. We just went through >> this pain, and the biosdevname scheme went through several iterations in the >> field and represents real-world lessons learned. Is there a compelling >> reason to make the systemd/udev policy for Fedora not just follow the >> existing solution to the same problem embodied in biosdevname? (Then, we >> could just phase out biosdevname.) > > biosdevname naming isn't apparently consistent across versions. > https://bugzilla.redhat.com/show_bug.cgi?id=782145#c21 > > The problems are roughly this: > - biosdevname only provides predictable naming for machines with SMBIOS > type 9 & type 41 records > - For other machines, it does 'best effort' based off of heuristics and > attempting to enumerate all the devices... which gives weird/unpredictable > results. > > This code has the benefit of: > - covering more device types (not just BIOSes with type 9 & type 41) > - not attempting to do heuristics that name devices via enumeration > > However, it does have the large disadvantage of changing the namespace used. That's certainly right. Here is a bit of the background that lead us here: Udev had the facility to try to keep the ethX names by writing out things to disk from the hotplug path. Looking back at it, it was a big mistake to ever even try this; it created far more problems than it has solved. People with virtualization or random MAC addresses ended up with 1000s of entries, one new for every reboot; in complex setups the renaming of interfaces in the kernel's namespace raced against the kernel creating new interfaces, ending up in device names like rename14, ..., and all these problems. That facility needed to die, that we are absolutely sure about. Now biosdevname was the envisioned future, it provided nice short names, based of static firmware properties or the physical path. So, that was the plan, but as soon as we started looking at the internals, it was not that convincing anymore. Biosdevname initially came up with the physical naming, but to accomplish the goal of "nice" names it enumerates the entire system and sometimes invents its own "pretty" numbers based on the *overall* view of the system. A model like that isn't really feasible for upstream udev, udev intentionally wants to be dumb and strictly prefers device-*local* views, and accepts possibly "uglier" hardware-provided properties, instead of "inventing" less reliable new "pretty" numbers. We had no better idea really, than to copy the successful model we do for disks (and other subsystems) with /dev/disk/by-*/ symlinks. It was a well-known scheme, but it was certainly not know for network devices so far. So we picked up the basic ideas from biosdevname and combined them with the proven scheme we do for all other subsystems in udev. This necessarily lead to different names, but from udev's point of view they are entirely justified. We will certainly never win a price for the prettiest names with what we do in udev now, but unlike the earlier solutions, it should be very simple, reliable and predictable. Just looking at 'lspci' will in most cases tell you what the name of the network interface will be. Thanks, Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Wed, Jan 23, 2013 at 7:50 PM, Lennart Poettering wrote: > On Wed, 23.01.13 18:04, Jaroslav Reznik (jrez...@redhat.com) wrote: > >> FedUp is in fact yum-upgrade as well, but in dracut environment (aka off-line >> upgrade). Some devels say that offline upgrade is only way. But on-line >> upgrade >> is possible. E.g in Debian world it is even prefered method. In Fedora exist >> upgrade using yum as unofficial method for long time. >> >> A lot of people are using upgrade using yum for long time and the "problem >> ratio" was at least on pair with Anaconda upgrade. In fact most problems >> comes >> from improper packaging. E.g. maintainer forgot to obsolete, so during >> upgrade >> user get file conflict. Once these problems are reported and fixed the >> upgrade is >> without problem. > > I'd strongly say "NO" to this. Not because I would have a problem with > people doing non-fedup upgrades (I tend to upgrade my machines with yum > myself, too). However, making this officially supported, and advertising > this as a feature appears to be the wrong move to me. > > The thing is that doing on-line updates only works for stuff you can > restart, and that doesn't mind that things are not atomically > updated. However, much (most?) of our code isn't like that. Anybody who > tried to update the Firefox RPM while it is running knows that this > doesn't end well, and you frequently have to manually kill firefox to > get it back into a usual state. > > Doing manual on-line upgrades with "yum distro-sync" is a fine > thing to do, but this requires people to understand that things might go > wrong, and requires a certain skill set from people so that they know > what to do if things go wrong (like for example knowing how to kill > firefox from the command line). But by making this an officially > supported feature fedora would suggest this as something that would work > for anybody, without any additional knowledge, and Fedora would have to > deal with the additional support work/bug burden this creates. > > It's OK if an RPM for this enters the archive, it's OK if people who > know how to fix their machines use this, it's OK if people suggest this > as hidden functionality. But I think it would be a big mistake for > Fedora to advertise this as official feature, and to accept the support > burden this creates. > > Fedora doesn't have unlimited resources, we have more than enough bugs > to fix anyway, making online updates an officially supported feature > would amplify this disparity. I, speaking for the stuff I'm involved and maintain, will certainly not work on things to make online upgrades work correctly, if they don't for whatever reason. It's a huge lie to pretend we can reliably do this, and just a I-hope-it-will-work-out thing not based on the technical reality. Anybody who claims this can and will always work flawlessly as a general model, seems not to understand the problems well enough. We all do these kind of updates ourselves, sure, and we surely don't want to make that impossible in the future; but it's nothing I personally would *ever* want to *support* on other people's systems. There is a reason we partly switched to offline updates now, it can at least work in the theory behind it, unlike the online updates. Please never try to *support* that officially, it cannot and will not work out. Thanks, Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
On Mon, Oct 22, 2012 at 7:26 PM, Mauro Carvalho Chehab wrote: > Em 17-10-2012 11:44, Matthew Miller escreveu: >> With the stipulation that rsyslog would still be available to provide a >> traditional syslog-style text logs, what are reasonable hard requirements >> for making systemd the main logging system installed by default? (Or, an >> alternate softer implementation: rsyslogd would be installed by default but >> would not be in 'core'.) > > Anything that is proposed to replace rsyslogd should be capable of getting > logs not only from a local machine, but also from network devices > (wifi, cable/xDSL modem, VoIP phone) and from other machines. Until > journald can't handle it, I don't think it is ready to be the default logger, > as it won't fill even my home network needs. > > So, the big missing feature seems to be syslog UDP/TCP protocol support. As mentioned earlier, that's is not a feature of the journal, it does not want to speak syslog as in the protocol, or write plain text files. It is what a syslog daemon is for, and what a syslog daemon already solves properly. There is absolutely no need to go wild here and try taking over what works fine since many years. The same applies to the plain text log files. It's both a solved problem the journal should just leave alone. If people want syslog, they should just run syslog, it all works fine, and is expected to be used that way. The journal is "system logging", but not "syslog" as in the text files, or the network protocol. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd requires HTTP server and serves QR codes
On Wed, Oct 10, 2012 at 10:06 PM, Richard W.M. Jones wrote: > On Tue, Oct 09, 2012 at 10:58:45AM +, "Jóhann B. Guðmundsson" wrote: >> Like to me rsyslog since the journal is an integrated part of systemd. > > Leaving aside the merits or otherwise of the journal, why does it need > to be part of systemd? Why not have it as a separate project? > (Perhaps requiring systemd, or as a plugin of systemd if it's really > needed.) > > The init system and logging have always been two different things. And init had never any idea what a service was doing after it double-forked, it could never monitor it, could not tell much about its current state, had no history about the behaviour, could not even safely shut it down. Systemd is a real service babysitter, and tracks everything across the entire life time of all services; the logs are just integral part of systemd's job. It also provides the kernel and userspace early boot logging support, and the out-of-the-box service stdout/stderr logging support; that's why the journal daemon is mandatory and not an add-on. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: replacing rsyslogd in minimal with journald [was Re: systemd requires HTTP server and serves QR codes]
On Wed, Oct 10, 2012 at 9:49 PM, Simo Sorce wrote: > On Wed, 2012-10-10 at 21:44 +0200, Kay Sievers wrote: >> On Wed, Oct 10, 2012 at 9:31 PM, Konstantin Ryabitsev >> wrote: >> > On Tue, Oct 9, 2012 at 5:24 PM, Lennart Poettering >> > wrote: >> >> I am not generally against adding time-based rotation, but really, this >> >> is much less of a "necessity" than other things the journal provides, >> >> which syslog does not: for example per-service rate limits, and >> >> unfakable meta-data for log messages. I mean, really, how can we ship >> >> a syslog where every random user can fake messages, say they are from a >> >> privileged process and offer no way how to detect that? >> > >> > I think you overestimate how much a sysadmin cares about fake >> > messages. The thing that's really important to a sysadmin is to make >> > sure that none of the REAL messages are lost. If someone fakes root >> > login entries by using something as trivial as "logger", I can easily >> > establish they are fake by looking at auditd logs. And then I would >> > *really* make that user regret their actions by using blunt >> > cryptanalysis tools. >> > >> > So, it's not accurate to say that we don't currently have ways to detect >> > that. >> >> That works only for very very few of the logged messages, and it is a >> good example how things should really not be designed or work today. >> >> We need one source of system log and not a bunch of daemons with all >> overlap but still have only parts of the picture, store their own >> stuff all over the place. >> >> Manual matching between the different data sources can sometimes be >> used to find out what was really going on, but that's really not good >> enough today. >> >> The journal daemon uses similar close-to-the-kernel properties to >> establish trust in logged messages, and in the future it is planned >> that it will also rad all audit messages directly. The audit daemon >> will then mostly be a policy execution engine for (rather exotic) >> requirements like "crash the box if the message does not go to disk". > > It seem your intention is to make the journal so much better that it > will be the preferred choice (and indeed the default). The journal is nothing really to choose, it's a mandatory core part of the operating system, systemd needs it itself, and it always runs. A running syslog daemon always gets its data forwarded only from the journal daemon. Syslog is by fact today already an "add-on", and not a required component, it is just installed by default today. I don't use or run syslog on any of my boxes since quite a while. > So make it really better and support time-based rotation. You don't need > to make time-based rotation the default, but you'll make a lot of people > happy to have the option. I really don't mind someone implementing a "maximum retention policy" for the journal, surely sounds useful for some setups, but I'm personally not really interested in implementing it. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: replacing rsyslogd in minimal with journald [was Re: systemd requires HTTP server and serves QR codes]
On Wed, Oct 10, 2012 at 9:31 PM, Konstantin Ryabitsev wrote: > On Tue, Oct 9, 2012 at 5:24 PM, Lennart Poettering > wrote: >> I am not generally against adding time-based rotation, but really, this >> is much less of a "necessity" than other things the journal provides, >> which syslog does not: for example per-service rate limits, and >> unfakable meta-data for log messages. I mean, really, how can we ship >> a syslog where every random user can fake messages, say they are from a >> privileged process and offer no way how to detect that? > > I think you overestimate how much a sysadmin cares about fake > messages. The thing that's really important to a sysadmin is to make > sure that none of the REAL messages are lost. If someone fakes root > login entries by using something as trivial as "logger", I can easily > establish they are fake by looking at auditd logs. And then I would > *really* make that user regret their actions by using blunt > cryptanalysis tools. > > So, it's not accurate to say that we don't currently have ways to detect that. That works only for very very few of the logged messages, and it is a good example how things should really not be designed or work today. We need one source of system log and not a bunch of daemons with all overlap but still have only parts of the picture, store their own stuff all over the place. Manual matching between the different data sources can sometimes be used to find out what was really going on, but that's really not good enough today. The journal daemon uses similar close-to-the-kernel properties to establish trust in logged messages, and in the future it is planned that it will also rad all audit messages directly. The audit daemon will then mostly be a policy execution engine for (rather exotic) requirements like "crash the box if the message does not go to disk". Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: replacing rsyslogd in minimal with journald [was Re: systemd requires HTTP server and serves QR codes]
On Wed, Oct 10, 2012 at 9:01 PM, Matthew Miller wrote: > Additionally, it _would_ be cool for log monitoring and analysis tools to > gain journald support, so that users of those tools can take advantage of > all the features Lennart lists. If we could have some of those in place > along with the proposed feature, that would be a win. Along with the ability to retrieve data from the journal, tools should probably start at the same time to support real message ids. They will allow us reliable recognition without weird regex matches in human readable syslog lines, allow catalogization of messages, documentation, metadata handling, or even localization. What we have in systemd so far is: http://cgit.freedesktop.org/systemd/systemd/tree/src/systemd/sd-messages.h We also have proper identifiers for devices/hardware in the kernel logs now. The journal reads them already and connects them to the current udev supplied data. These identifiers should also be used to identify a device instead of the unreliable guessing of strings in human readable syslog messages: http://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: replacing rsyslogd in minimal with journald [was Re: systemd requires HTTP server and serves QR codes]
On Wed, Oct 10, 2012 at 8:44 PM, Konstantin Ryabitsev wrote: > On Wed, Oct 10, 2012 at 2:39 PM, Kay Sievers wrote: >>> So, in other words, all our existing log analysis tools have to be >>> modified if they are to be of any use in Fedora 18? >> >> What part of "Run the syslog daemon like you always did, if you need >> syslog files." did you not understand? > > Well, hang on, Kay. My understanding was that we're trying to make > syslog an optional install in Fedora 18 (or is it 19?). Surely not f18, and there is not even a feature for f19 as of now. > If that is the > case, then even if I require rsyslog for a package, that won't work > unless rsyslog is started and running. Services can pull-in service dependencies to start stuff they depend on, it's unreleated RPM dependencies. > So, sysadmin's experience > changes: > > Was: Install logwatch. > Becomes: Install logwatch. Make sure you install and enable rsyslog. > > I just want to make sure people are aware of the change. Ah, sorry that I was just unable to translate: "all our existing log analysis tools have to be modified if they are to be of any use in Fedora" to "just want to make sure ... you install and enable rsyslog". :) Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: replacing rsyslogd in minimal with journald [was Re: systemd requires HTTP server and serves QR codes]
On Wed, Oct 10, 2012 at 8:37 PM, Konstantin Ryabitsev wrote: > On Wed, Oct 10, 2012 at 2:32 PM, Lennart Poettering > wrote: >>> Can journalctl send the logs via logwatch? >> >> Not sure I can parse this, but IIUC you are wondering whether logwatch >> is compatible with the journal. Not to my knowledge, no. But adding this >> should be fairly easy as the output of "journalctl" is a pixel-perfect >> copy of the original format, so where it works on /var/log/messages it >> should simply work on the output of journalctl and all should be good. >> >> Note however that with the capabilities of the journal it might be >> interesting to add journal support to logwatch that goes beyond mere >> compatibility. For example, tests such as "look for messages which are >> claimed to come from PID xyz but actually came from uvw" and suchlike >> would be really interesting to have. That information is not available >> in the /var/log/messages format however... > > So, in other words, all our existing log analysis tools have to be > modified if they are to be of any use in Fedora 18? What part of "Run the syslog daemon like you always did, if you need syslog files." did you not understand? Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: replacing rsyslogd in minimal with journald [was Re: systemd requires HTTP server and serves QR codes]
On Wed, Oct 10, 2012 at 5:05 PM, Miloslav Trmač wrote: > On Tue, Oct 9, 2012 at 11:24 PM, Lennart Poettering > wrote: >> which syslog does not: for example per-service rate limits, > > False. http://www.rsyslog.com/doc/imuxsock.html, "There is input rate > limiting available", currently enabled by default in Fedora. Insufficient in rsyslog. And it's right what Lennart said. This really needs to be per service/user not per pid. Pids are almost entirely useless to key-off here. >> and >> unfakable meta-data for log messages. > > False: http://www.rsyslog.com/doc/imuxsock.html, "trusted syslog > properties are available" (and in v7 they can be enabled in the Fedora > configuration by default) It's well meant, but really, it sounds more like a joke. Adding "garbage" to the end of the human readable plain text is not comparable with the journal. > On Wed, Oct 10, 2012 at 12:08 AM, Lennart Poettering > wrote: >> I am not a security guy, but having >> logs where unprivileged users cannot insert undetectable fakes > (Re: the implied claim that systemd provides that): It surely does provide it. Rsyslog can do something similar, but really, with pushing stuff into plain text files, mixing it into the human readable message it can't really get too far without creating a mess in the files. > For the "unprivileged user" part, see above. > > For the cryptographic protection, false. It's not about tamper-proof log files, it was about unfakeable message source context. > http://cgit.freedesktop.org/systemd/systemd/tree/man/journalctl.xml#n358 > defaults to 15 minutes, which is an eternity. The sealing was not even mentioned, but it's still better than nothing. And 15 min are the current default, and this will change as soon as the details are hashed out to efficiently move the sealing forward in time. > [1] An adjective belongs here. I can think of about 10 candidates, > but I feel too ill and grumpy to trust myself to choose well. I'm sure you should wait until you are back to full speed. You comparision seem pretty bad researched. :) Thanks, Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Tue, Sep 11, 2012 at 6:18 PM, Lennart Poettering wrote: > On Tue, 11.09.12 09:52, Kevin Fenzi (ke...@scrye.com) wrote: > >> > > This would give packagers much more flexibility about branching and >> > > would also simplify our model as the master branch would just go >> > > away... One branch less that can be confused is a win for >> > > everybody. >> > >> > I don't see a problem with that, but then I'm just the monkey :) >> >> So, the biggest problem is that in the past, FESCo has said that >> rawhide should never "go back" in versions. If we change the >> inheritance to pull from say f18-updates-testing, it means if an update >> was pulled it also would 'disappear' from rawhide the next day. >> >> If I was wanting a f19 branch for my big library build and I needed to >> build a new systemd version, could I branch it? or that would only be >> up to you? (ie, would it be any package maintainer, or just people with >> acls to the package). > > Everybody with commit access to he package should be able to create a > branch of it I guess. > >> How do we tell pkgdb that there is a new branch? Currently it's done >> at mass branch time, but in this model there would have to be some way >> for maintainer/brancher to tell it. > > Well, maybe the "mass branch time" should continue to exist, but instead > of actually doing any mass branching it would just be the point in time > where pkgdb learns that a new branch might now exist in the package > repos even though many packages won't have it any time soon. Wouldn't it already help if the build system would just refuse to build newer versions in branches than which are in rawhide at that moment? Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Changes to the Packaging Guidelines
On Fri, Aug 3, 2012 at 12:56 PM, Peter Lemenkov wrote: > 2012/8/3 Lennart Poettering : >> On Wed, 01.08.12 15:28, Tom Callaway (tcall...@redhat.com) wrote: >> >>> A new section on Macros has been added to the Packaging Guidelines, >>> covering Packaging of Additional RPM Macros. >>> >>> https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_of_Additional_RPM_Macros >> >> What's the rationale behind having these in /etc? This is hardly user >> configuration, and only ever used if people build their own RPMs. We >> really should try harder not to clutter /etc with stuff that is not >> configuration. >> >> Why not have this somewhere below /usr? > > Agree. We should install them into /usr/lib/rpm. Exactly. Static stuff installed by packages should not land in /etc. It's a pain on updates when it's marked as config, and stuff goes wrong all the time, because things in /etc invite everybody to edit it, and boom. We really should try hard to leave /etc to the admin, and not the OS vendor. And just in case that this will come up: all the bad prior art in /etc should not be a reason to continue that road, it's not the right way, and we can do better, and need to do better. :) Thanks, Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide: libudev version bump, merged into systemd, libudev user need rebuild
We merged the upstream udev repository entirely into the systemd repository. There is no standalone upstream udev project anymore. The version of systemd which includes udev has landed in rawhide a couple of days ago. Fedora 18 will not have a udev.rpm, no libudev.rpm and no libudev-devel.rpm. The libgudev1.rpm and libgudev1-devel.rpm are provides the same way as before and will still exist. Please remove all udev dependencies in packages which link against udev. They should now just use: Buildrequires: systemd-devel If a versioned dependency is needed, please use: Requires: systemd > XXX The systemd version number jumped to the next version of the last release of udev, it is currently 185. Systemd includes libudev.so.1, while the old libudev.rpm provided libudev.so.0. Therefore, all packages using udev need to be rebuilt. These symbols are no longer provided by libudev.so.1: - udev_monitor_new_from_socket() custom application sockes are no longer supported by udevd, use the usual udev_monitor_from_netlink() - udev_queue_get_failed_list_entry() failed events are not recorded by udev since a long time, code that used this can just be removed - udev_get_dev_path() udev_get_sys_path() udev_get_run_path() systemd does not allow to configure any of these filesystem paths, they should simply be hard-coded and be replaced by "/dev", "/sys" and "/run/udev" Thanks, Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /etc/default in Fedora
On Tue, Mar 6, 2012 at 17:21, Daniel J Walsh wrote: >> Why /etc/default dir is used instead of /etc/sysconfig? To be >> honest - it's not really user friendly from long time RH Linux user >> POV. >> > Just disable SELinux in /etc/selinux/config. Which is exactly the use model of /etc we recommend everybody to follow. /etc is *system config* and might be *default*, using another subdirectory with that name is superfluous. /etc/defaults/ makes no real sense to start with. It's either a 'default', then it belongs into the service compiled-in, or it is local *system config* data, and then it's not a *default* anymore. People who introduced that the first time seem just confused by default. :) /etc/sysconfig/ is a fedora'ism that we try to avoid as much as possible. It only manifests the Linux balkanization, which hurts everybody in the end. We shoud phase that out, it should only be reserved for legacy hacks nobody wants to fix, and not be used for anything new. So, please all just use a subdir directly in /etc with the name of the package/subsystem, and put your files in there, that's what /etc is for, it is already *default* and *system config*. And please name and layout everything in a way that upstream can ship it identical for every distro, we really need to end the useless differences between the distros. Thanks, Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Mon, Feb 20, 2012 at 21:25, Nicolas Mailhot wrote: > Le Lun 20 février 2012 21:20, Nicolas Mailhot a écrit : >> Le Lun 20 février 2012 21:07, Kay Sievers a écrit : > >>> I couldn't disagree more. >>> >>> /usr/share in our general understanding not to be used for >>> package-private things. >> >> But those files are not package-private! Even ignoring the example I just >> gave, systemd units *will* be installed by different packages that *will* >> need >> to be at least aware of the other units to handle ordering properly. Those >> files are anything but package-private > > (and actually it's quite ridiculous to have systemd people argue today unit > files belong to them alone when they've spent the past years reusing files > that were intended for sysv. Someday something better than systemd will be > proposed and it will have to read 'systemd' files just like systemd had to > read 'sysv' files to handle the transition) It all started with udev 7 years ago, and it still makes sense taking into account all the experience we collected in that time. Find it ridiculous or not, it's what we think is right. Even if we were not sure about it, changing the well-established way we do it would not be justified. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
2012/2/20 Miloslav Trmač : > On Mon, Feb 20, 2012 at 9:17 PM, Kay Sievers wrote: >> The general rule for $libdir is that it is reserved for shared objects >> and their directly associated files like pkgconfig files. > No, that's not at all what the FHS says. "Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory." > Please don't claim that any > suggested meaning, however reasonable it may be, is "the general rule" > when it isn't. I do. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Mon, Feb 20, 2012 at 20:18, Toshio Kuratomi wrote:
> On Mon, Feb 20, 2012 at 06:30:11PM +0100, Lennart Poettering wrote:
>> On Mon, 20.02.12 09:25, Toshio Kuratomi (a.bad...@gmail.com) wrote:
>> > This sounds like the unit files belong in %{_libdir} now? However, that
>> > would mean that they can't go into noarch packages. So we probably need to
>> > know a little more about just how architecture dependent these unit files
>> > can be.
>>
>> No, not %{_libdir}, but rather %{_prefix}/lib. (i.e. we do not want to ship
>> two different versions for 32bit and 64bit. We want just one, hence they
>> belong in /lib unconditionally)
>>
> Okay, so this is one more area where when people mispackage a library and
> a program in the same subpackage, they'll get bitten?
I'm convinced that the default of $libexedir should just be set to
/usr/lib and all packages using libexecdir should use a subdir in
that, and $libdir should not be involved at all, this results in
/usr/lib/udev/cdrom_id, and /usr/lib/systemd/systemd-journald and so
on. This is actually what most distributions do today and what we
envision for the future of a cross-distribution unified Linux.
The general rule for $libdir is that it is reserved for shared objects
and their directly associated files like pkgconfig files.
There are valid cases where shared objects exec() their own helpers,
like when elevated privileges and setuid/capabilities are involved,
that can be a good and valid reason to drop the binary in $libdir if
multilib installation with separate callout helpers need to be
supported; but almost all other packages should not mess there.
Kay
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Mon, Feb 20, 2012 at 20:42, Nicolas Mailhot wrote: > > Le Lun 20 février 2012 18:50, Kay Sievers a écrit : >> On Feb 20, 2012 6:25 PM, "Toshio Kuratomi" wrote: > >> Udev rules and systemd units belong to the installed daemon. This daemon >> can only exist exactly one single time, and never be installed by multilib >> packages, hence they do not ever belong into libdir. > > Actually, Udev rules and systemd units belong to the package that installed > them. That's why hiding them in a private lib dir is wrong > > When amavisd instaciates clamav using the generic unit shipped with clamav but > using an amavisd-specific conf file the clamav systemd unid is shared with > amavisd > > That's why share is the natural place to share this arch-independant > configuration and putting it in /usr/lib is grandfathering an exception that > only existed because /share didn't exist I couldn't disagree more. /usr/share in our general understanding not to be used for package-private things. There is no reason to have /usr/share// and /usr/lib/, even LSB specifies that only a _single_ dir should be used, hence the one in lib not in share. Even the original distinction between arch-dependent and arch-independent to support a share/ subdir that can be *shared* between different machines will break with config like udev and systemd in share/. This is not a *natural* place at all. We tend to interpret /usr/share as something today, to place stuff into that is really *shared* on the same host, like icons, man pages, things that are mere a collection of similar stuff that multiple packages use. It's definitely not a place to store system instructions and system plugins. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Feb 20, 2012 6:25 PM, "Toshio Kuratomi" wrote:
> This sounds like the unit files belong in %{_libdir} now? However, that
> would mean that they can't go into noarch packages. So we probably need
to
> know a little more about just how architecture dependent these unit files
> can be.
There is some serious confusion going on here with Fedora and libexec, not
only regarding the lib/ vs share/ problem.
The recommended defaults as mentioned in the packaging guidelines are just
plain wrong. The recent bug we opened regarding this was just closed
wontfix.
Udev rules and systemd units belong to the installed daemon. This daemon
can only exist exactly one single time, and never be installed by multilib
packages, hence they do not ever belong into libdir. We support compat arch
only, not multiarch. Multiarch would look completely different anyway, and
compat arch does not need or want to involve libdir here.
The rules and units belong in 'libexecdir' which is upstream, and by LSB,
called and defined as /usr/lib/. Putting anything like that into
libdir is just wrong.
What the Fedora guidlines recommend here is not only wrong, it is also
playing bad with upstream, and as mentioned in the bug, I personally
consider it upstream-unfriendly, upstream-ignorant and against all common
sense in reducing the Linux distro balcanization, and just a bad example
how not to package tools today.
Please stop recommending or installing tools or other non shared objects in
libdir, they almost never belong there. I can see that a few exceptions can
be granted here, because it makes it easier to support binaries, that are
actually exclusively and directly bundled with a shared object, but
everything else just does not belong into libdir.
Thanks,
Kay
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Mon, Feb 20, 2012 at 13:51, Lennart Poettering wrote: > On Mon, 20.02.12 13:32, Nicolas Mailhot (nicolas.mail...@laposte.net) wrote: >> Le Lun 20 février 2012 13:02, Lennart Poettering a écrit : >> >> > Something similar applies to udev rules and similar "almost code" bits. >> > >> > But yeah, I know people will disagree with us on this. >> >> Lennart , you realise, do you, that people are unlikely to fix the historical >> exceptions they've benefited from as part of systemd or usrmove if you're >> championing the creation of new exceptions for your own sake in >> parallel. It's not a new exception, it's the reality for udev since ~6 years. > This isn't really a "new" exception for me. There's a ton of files that > are not strictly arch dependent in bin, lib, libexec. Shell scripts, > Python scripts, udev rules, pkg-config files, a ton of rpm files, LSB > symlinks, Java files, Ruby files, yadda yadda yadda. > > The thing is simply that there are cases where things are clear that > they belong on /lib, and others where it is clear that they belong in > /share. And then there is this huge grey area in the middle of those > files where things aren't super clear. The line between /lib and /share > is blurry. And since about always people then ended up coming to > different conclusions and hence dropped some stuff that you don't think > belongs in /lib into that very dir, and some stuff that others don't > think belongs in /share into that very dir. > > I think a rule of "if in doubt, /lib is preferable" is the safe choice > here though. In the case for unit files we have a couple of good reasons > to consider them arch-specific enough beyond just mere "if in > doubt". (see my earlier mail for them). I second that. >> Systemd unit files are no more cody and app-specific (and in fact quite a lot >> less) than emacs lisp files or java jar files or docbook xslt processing >> rules >> or a lot more stuff I'm forgetting about right now and those have been in >> /usr/share for a *long* time. > > I see a ton of jar files in /usr/lib here actually. > > The world isn't black and white. The separation between /share and /lib > is more complex than simple binary logic. That sounds right. And for the same reason, the udev rules need to stay in lib/ and not move to share/. Udev rules are not meant to be *shared* across anything, not across different machines, not across architectures, not across multiple packages. They only get installed _for_ the udev version that is the primary architecture, and there can only be one udev version installed on a system. The rules get installed by multiple packages, sure; but they do not involve any, and must actually prevent any sort of *sharing*. The very same that is true for udev, is true for sytemd units. Rules and units do not provide any additional or optional data, they influence the actual global system runtime behaviour, they change and extend the system, very much like a service plugin or a shared object. That they are actually text file, is an implementation detail that should not have influence on the installation directory. Thanks, Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On Fri, Feb 3, 2012 at 11:25, Frank Murphy wrote: > On 02/02/12 18:47, Kay Sievers wrote: >> >> The former dracut ‘usrmove’ module has been renamed to ‘convertfs’. We >> need to carry that option for quite some time through future releases > > Does this mean that ‘convertfs’ will be build into dracut-*? The module will be provided by dracut for at least the next two Fedora releases, to be able to upgrade older installations with just yum. > Does the user\tester have to keep doing "--force --add"? For now, the module is not included by default. We will have a call to that script in anaconda, so updates from media will not need any of these steps. Manual updates with dracut will need that. > Does rd.convertfs have to stay on /etc/grub.cfg > Shoule we adjust /etc/dracut.conf "add_extramodules=convertfs" Only once, It can also be be entered one time at the bootloader. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On Fri, Jan 27, 2012 at 14:10, Harald Hoyer wrote: > Hello Testers and rawhide Users, > > Fedora 17 will locate the entire base operating system in /usr. The > directories > /bin, /sbin, /lib, /lib64 will only be symlinks: > /bin → /usr/bin > /sbin → /usr/sbin > /lib → /usr/lib > /lib64 → /usr/lib64 > > Some reasoning behind this change is outlined here: > http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge > > The official Fedora 17 feature page is here: > https://fedoraproject.org/wiki/Features/UsrMove > > The needed changes to implement the unified filesystem are about to land in > rawhide soon. New installations of rawhide/Fedora 17 will install the symlinks > right away, and no special care needs to be taken > > Currently installed systems need some manual steps to convert the current > system > to match the layout of rawhide/Fedora 17. After that, the system can continue > to > be updated with YUM as usual. > > Some RPM packages in rawhide/Fedora 17 will carry a RPM dependency guard, > which > will make sure, they can only be installed when /bin, /sbin, /lib, /lib64 are > symlinks and not directories like in Fedora 16 and older. > > The installed system’s base filesystem layout can not be safely altered, while > the system itself is running on top of it. Dracut, the initramfs used to find > and mount the root filesystem, can be instructed to convert the filesystem to > match rawhide/Fedora 17’s expectations. The former dracut ‘usrmove’ module has been renamed to ‘convertfs’. We need to carry that option for quite some time through future releases and want to name the module more generic for possible future needs in that category. This is the current version/build number: dracut-014-81.git20120202.fc17 Please build the custom dracut image now with: # dracut --force --add convertfs On the kernel commandline dracut now looks for: rd.convertfs In some cases, we still do not properly support multi-lib updates with the current testing repo, without adding also the i386 repository to the updated system; the f17-usrmove repo does not automatically copy the 32bit libs in the 64bit repo. This issue will not happen when all moves to rawhide. These known bugs are fixed: - rebuild of the dracut initramfs on the converted system had problems with optimized i686 libs, which is fixed now - the ntfs-3g was not part of the f17-usrmove repository and installing the old package on the converted system broke its symlink logic. The fixed package is built for f17-usrmove now. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On Tue, Jan 31, 2012 at 23:36, Adam Williamson wrote: > On Tue, 2012-01-31 at 14:23 -0800, Adam Williamson wrote: >> On Fri, 2012-01-27 at 14:10 +0100, Harald Hoyer wrote: >> > Hello Testers and rawhide Users, >> > >> > Fedora 17 will locate the entire base operating system in /usr. The >> > directories >> > /bin, /sbin, /lib, /lib64 will only be symlinks: >> > /bin → /usr/bin >> > /sbin → /usr/sbin >> > /lib → /usr/lib >> > /lib64 → /usr/lib64 >> >> I've just tested building a live image from the /usr move repository. It >> boots, and the /usr move changes appear to be implemented. I'm currently >> testing if it can be installed successfully. >> >> One thing I already noticed is that there seems to be a problem with the >> ntfs-3g executables. /bin/ntfs-3g seems to be a symlink to itself - it >> shows as "/bin/ntfs-3g -> /bin/ntfs-3g" in ls output. Trying to do 'ls >> -l /usr/bin/ntfs-3g' results in 'cannot access /usr/bin/ntfs-3g: Too >> many levels of symbolic links'. /bin/ntfsmount is similarly affected. >> >> On a pre-/usr move system it seems that these executables are actually >> located in /bin but have symlinks in /usr/bin - /usr/bin/ntfs-3g is a >> symlink to /bin/ntfs-3g . Perhaps the existence of these symlinks >> in /usr/bin confused things? Oh, for some reason, we missed to add ntfs-3g to the packages in the f17-usrmove repo. The unconverted package contains: /usr/bin/ntfs-3g -> /bin/ntfs-3g which needs to be fixed to work properly for the usrmove. > Installation fails at partitioning stage, with udisksd hitting "Error > opening /etc/crypttab file: Failed to open file '/etc/crypttab': No such > file or directory (g-file-error-quark, 4)" > > The file /etc/crypttab indeed doesn't exist. I'm not sure if this is > actually specific to the /usr move stuff, but it does prevent me being > able to ensure that installation works from a /usr-moved live image. I > have a non-usr-move image also, I'll test install with that. Sounds unlikely that this is related. But tests should show. Unrelated: Do you know if the installer uses udisks? If, it should probably switch to the current udisks2, because udisks will not much longer be supported, and we should people give a note about that. Thanks, Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd and fstab
On Wed, Dec 14, 2011 at 14:01, Lennart Poettering wrote: > On Wed, 14.12.11 12:25, Andrew Price (anpr...@redhat.com) wrote: >> From the systemd.mount(5) man page: >> >> "Mount units may either be configured via unit files, or via /etc/fstab" >> >> This makes me wonder - to what extent will systemd replace fstab in >> future Fedoras? Will fstab disappear in favour of systemd mount >> units? > > I see no reason why we should drop fstab. I only see reasons against > dropping it, for example in the fact that glibc kinda hardcodes its > existance in the setmntent() API. > > There are a couple of things you can do if you configure a mount unit > via systemd, instead of fstab, which you can't do with fstab (for > example, defining manual dependencies), which is why we added support > for that, but thtat doesn't mean it's supposed to replace fstab. Might be worth noting, that today fstab should only contain 'real system mounts'. No virtual filesystem should be added by default to fstab, they all are managed by systemd natively or with additional units. And yeah, it's very unlikely that fstab will go away anytime soon, we surely don't aim for that at the moment. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads Up: FESCo is considering to block packages providing sysvinit services without systemd unit
2011/11/9 "Jóhann B. Guðmundsson" :
> On 11/09/2011 05:49 AM, Ian Kent wrote:
> That only leaves this relevant sections from that quick look that needs
> some work and remains questionable if that should be handled in unit
> file et all...
>
> # Check misc device
> if [ -n "$USE_MISC_DEVICE" -a "x$USE_MISC_DEVICE" = "xyes" ]; then
> sleep 1
> if [ -e "/proc/misc" ]; then
> MINOR=`awk "/$DEVICE/ {print \\$1}" /proc/misc`
> if [ -n "$MINOR" -a ! -c "/dev/$DEVICE" ]; then
> mknod -m 0600 /dev/$DEVICE c 10 $MINOR
> fi
> fi
> if [ -x /sbin/restorecon -a -c /dev/$DEVICE ]; then
> /sbin/restorecon /dev/$DEVICE
> fi
> else
> if [ -c /dev/$DEVICE ]; then
> rm /dev/$DEVICE
> fi
> fi
>
Just kill it. The kernel creates the device nodes today, nothing is
supposed to fiddle around like this in /dev in 2011.
We even support auto-loading of the kernel module these days, on
access of the device node which udev creates when the modul is
available (only needs to be available, not even loaded).
Kay
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature
On Thu, Oct 27, 2011 at 10:51, David Tardon wrote: > On Thu, Oct 27, 2011 at 10:38:15AM +0200, Michal Hlavinka wrote: >> On 10/27/2011 10:34 AM, Harald Hoyer wrote: >> >> That would also mean that libreoffice (using /usr/lib*/libreoffice) >> should have all binaries there? I guess not. > > It has always been that way. There are only shell scripts in /usr/bin. > (Moreover, the /usr/lib*/libreoffice/program/soffice called from > /usr/bin/libreoffice is another shell script that execs the real > binary.) Ideally, all 64bit libraries it installs would be in /usr/lib64/libreoffice/*, and all text files, java archives and executables (and possibly 32 bit libraries) live in /usr/lib/libreoffice/*. The lib64 directory is in theory reserved for shared libs only, and not suppossed to contain anything else. I don't know about the specifics of libreoffice, but multilib can be a real mess in the real world. Most complex apps can't really mix 32 and 64 bit data and binaries, even when they theoretically run fine on the architecture. So the current packaging seems like the best compromise. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature
On Thu, Oct 27, 2011 at 10:46, Harald Hoyer wrote: > 4.6. /usr/lib : Libraries for programming and packages > > 4.6.1. Purpose > > /usr/lib includes object files and libraries. ^[22] On some systems, it > may also include internal binaries that are not intended to be executed > directly by users or shell scripts. ^[23] /usr/lib// is the preferred way to do it. Udev does this since forever, and systemd does the same. LSB itself uses /usr/lib/lsb/. I think 'libexec' is just a weird name, and should be faded out over time. Fedora was the only major distro which used that, it never existed on other distributions, and we want less needless differences here. What we want for sane packaging is an 'application private directory' not something just for executables. Application configuration like udev rules or systemd service files (init scripts) need to live in that directory too, and 'libexec' really doesn't sound right for that. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file: Can/Should ExecStart and ExecStop run a script?
On Wed, Oct 19, 2011 at 23:35, Richard Shaw wrote: > On Wed, Oct 19, 2011 at 4:27 PM, Kay Sievers wrote: >> On Wed, Oct 19, 2011 at 23:20, Richard Shaw wrote: >>> On Wed, Oct 19, 2011 at 3:58 PM, Tom Hughes wrote: >>>> On 19/10/11 21:48, Richard Shaw wrote: >>>>> >>>>> On Wed, Oct 19, 2011 at 3:26 PM, Lennart Poettering >>>>> wrote: >>>>>> >>>>>> You should manage acess control of device nodes from udev rules. That's >>>>>> the only reasonably safe way to handle these things. And this should not >>>>>> be mentioned at all in systemd unit files. >>> >>> Ok based on Tom's file I came up with the following. I know Lennart, >>> you don't like setting ACL's from Systemd, but unless someone want's >>> to help me write udev rules that will run before the start of >>> mythbackend and after it's stopped, this is all I have: >> >> Yeah, that looks very wrong. >> >> Like mentioned earlier in this thread, just put the user into the >> audio/video system group and forget about any permissions management. > > That works for me. I wonder if I could use ExecStartPre to run a shell > script to make sure the user is in those groups and write to stderr if > not? That's a job for a %pre RPM script, not a service. Create the user and put the user in the group when the package is installed. > Also, the shell expansion doesn't work on ExecStart, so how to I set > the user in the command line? Hardcode it. It does not make much sense to configure something, or use config file indirections for stuff that does not need to be changed anyway. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file: Can/Should ExecStart and ExecStop run a script?
On Wed, Oct 19, 2011 at 23:20, Richard Shaw wrote: > On Wed, Oct 19, 2011 at 3:58 PM, Tom Hughes wrote: >> On 19/10/11 21:48, Richard Shaw wrote: >>> >>> On Wed, Oct 19, 2011 at 3:26 PM, Lennart Poettering >>> wrote: You should manage acess control of device nodes from udev rules. That's the only reasonably safe way to handle these things. And this should not be mentioned at all in systemd unit files. > > Ok based on Tom's file I came up with the following. I know Lennart, > you don't like setting ACL's from Systemd, but unless someone want's > to help me write udev rules that will run before the start of > mythbackend and after it's stopped, this is all I have: Yeah, that looks very wrong. Like mentioned earlier in this thread, just put the user into the audio/video system group and forget about any permissions management. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file: Can/Should ExecStart and ExecStop run a script?
On Wed, Oct 19, 2011 at 22:26, Lennart Poettering wrote: > On Wed, 19.10.11 13:43, Richard Shaw (hobbes1...@gmail.com) wrote: > >> It looks like I'll be taking over mythtv packaging for RPM Fusion and >> I noticed it still only uses a sysv init script. >> >> In the sysv script it sets some ACL permissions on video and audio >> devices necessary for the backend service, and then on shutdown >> changes it back. >> >> I don't see any way to accomplish this in a systemd unit file other >> than running a script. >> >> What's the right way to do this? I have a template unit file (not >> meant to "work" yet): > > You should manage acess control of device nodes from udev rules. That's > the only reasonably safe way to handle these things. And this should not > be mentioned at all in systemd unit files. All video and audio devices have a proper default group ownership. These groups exist only for system daemons like this. System groups are not supposed to be used by users. There is no support for ACLs setups for system services. ACLs are usually used for logged-in users only. Just put the user the process runs with in the audio and video group. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 beta vice Knoppix
On Wed, Oct 5, 2011 at 15:28, Lennart Poettering wrote: > On Tue, 04.10.11 19:40, Adam Williamson (awill...@redhat.com) wrote: >> On Tue, 2011-10-04 at 16:55 -0800, Jef Spaleta wrote: >> > On Tue, Oct 4, 2011 at 3:32 PM, JB wrote: >> > > 13837ms udev-settle.service >> > > 11392ms plymouth-start.service >> > >> > >> > if you use the plot option instead of blame option and produce the svg >> > of the service timing you get a better feel for what Lennart was >> > talking about with regard to the udev settle being problematic. >> > >> > I'll try to break it down for you. Keep the following in mind when you >> > look over the svgs produced in susequent testing. >> > >> > udev-settle.service essentially calls udevadm settle and that's all it >> > does. >> > udevadm settle takes FOREVER (15 seconds) to return during boot up on >> > my live media run But its returns more quickly on on F15 install (3 >> > seconds). I'll check a full F16 beta install soonish. >> >> And remember that all udevadm settle does is wait for the udev event >> queue to empty. >> >> So essentially all that's going on here is 'wait for udev to be done', >> which is a fairly sensible prerequisite for all manner of other bits of >> boot. > > Nah, this is not a sensible prerequisite. User code should *not* have to > wait for udev to be settled. > > They key message Kay and I and everybody else involved in udev/systemd > and related technologies want to get into everybodies head is that > applications should never ever expect that "everything is settled", > since that is simply not possible (i.e. USB init times are unbounded -- > so how do you know that the usb disk fully initialized when you settled > the udev queue?) and all attempts to fake that are major sources of > slowness at boot (to deal with USB and stuff people basically just wait > a couple of seconds, which doesn't fix the problem, just tapes over it). > > Or in other words: "udev settle" is a hack and is not part of our boot > anymore -- unless LVM pulls it in. And the fact that it pulls it in is > sad, and has been a constant source of complaining from us to the LVM > folks over the years. > > They major point to make here is that all components of the system > should wait exactly as long as they have to and not longer. More > specifically: they should wait for the specific hardware they are > needing but not any longer. Example: when mounting the file systems > systemd will wait exactly until the point all devices listed in > /etc/fstab have shown up -- but not any longer before continuing. > > And again, in short words: > > "udev settle" is a hack. Only broken code needs it. It has no place in a > modern system. > >> The reasons why udev takes a while to be 'done' are more interesting and >> Lennart went into some of them. > > It is completely fine if some probing done by udev rules takes a long > time. It's not just fine, it's even expected. For example, I have a 3G > card in my laptop I don't use. Since it has no SIM card it takes about > 8s seconds to probe (i.e. the firmware finds it funny to reply with an > 8s delay to AT commands if no SIM card is in the card). Now, there's no > sensible way around this, since the the hw just takes that long to > probe. As long as these 8s are spent in the background they shouldn't > matter at all. Except that LVM requires settling of all devices, and > hence simply enabling LVM means my boot is delayed for a whole 8s. Now > thankfully, I opted out of LVM when I installed Fedora on my > machine. That way the 8s probing of the modem continues in the > background long after gdm is already up. > > That's why I mentioned in that earlier mail to ajax that I am not > concerned that EDID takes so long: because it is OK. What isn't OK is > that LVM has to wait for EDID and for my 3G modem probing to complete, > and thus delays our entire boot. > > LVM needs to be ported to listen to hotplug events, and make use of > devices as they show up, instead of expecting that all hardware has > already shown up and has been probed before LVM is started. For a number > of reasons: to not slow down the boot artificially, to fix the > enumeration race and become fully compatible with today's storage > technology that is much more dynamic than 10 years ago, and to become > robust. > > Please, don't claim that "udev settle" was a sensible prerequisite. It > isn't. It has no place in today's dynamic hardware. Just to make sure that the message is clearly understood and there is nothing sensible in making any assumptions ever, like: 'all devices are there / we have settled'. That can never be true on today's systems. Any system service that today relies in its core on 'udevadm settle' or scsi-wait-scan module, or any of the other bad hacks in that category, anything that uses these barriers as a checkpoint to block on, to do its synchronous actions, should be considered non-hotplug capable, need to be fixed or legacy. The Fedora storage assembly shell scri
Re: Fedora 16 beta vice Knoppix
On Wed, Oct 5, 2011 at 15:09, Lennart Poettering wrote: > On Tue, 04.10.11 19:38, Adam Williamson (awill...@redhat.com) wrote: >> >> On Tue, 2011-10-04 at 15:53 -0800, Jef Spaleta wrote: >> > On Tue, Oct 4, 2011 at 3:32 PM, JB wrote: >> > > Let me append "The Blame Game". >> > > # systemd-analyze blame >> > > 32983ms livesys.service >> > > 22828ms NetworkManager.service >> > >> > That timing for NM is so vastly different than what I'm seeing on my >> > installed F15 system. I am intrigued. >> >> His numbers are all huge as he's booting live, either from an actual >> rotating shiny disc thing (the antiquity of it all!) or a USB stick. >> Either of which is going to be slower than an HD or SSD. > > If this is indeed a boot from CD then it's not really surprising our > numbers are bad since seek times on CDs are awful. If people want to > spend optimizing the boot time here it should be possible to reorder the > files on the squashfs image to minimize seeking. mksquashfs has the > -sort option for that. The data would have to be generated in a two-pass > way: first burn and boot the unordered image, use it to determine the > access order, then pass that to mksquashfs and generate a second, > ordered image. You could use systemd-readahead-collect to collect that > access order information, but you'd need to write a tool to convert > systemd's format to something readable by mksquashfs. > > Optimizations like this are always thinkable, but then again spending > the time on optimizing CD boots sounds like a lot of time wasted on > yesterday's technology. Might be interesting to just compare the CD boot speed with the same image on a USB stick. That should giva an idea. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On Tue, Jul 19, 2011 at 18:21, Bill Nottingham wrote: > Kay Sievers (kay.siev...@vrfy.org) said: >> On Mon, Jul 18, 2011 at 23:27, David Michael wrote: >> > On Mon, Jul 18, 2011 at 5:16 PM, Bill Nottingham >> > wrote: >> >> Right, but that then causes 'last one wins' behavior among multiple DMs. >> >> >> >> I suppose we could use alternatives for this, as much as I dislike it. >> > >> > I meant creating that symlink was the replacement for >> > /etc/sysconfig/desktop, the end-user configuration. >> >> Yes, this link will replace the config file. >> >> > As for what packages do about their DM service files, I would agree >> > with letting alternatives manage a default >> > /lib/systemd/system/display-manager.service symlink, >> >> We should not let packages create config files in lib, lib is more for >> static content from rpms, not really for configuration. For the same >> reason, 'systemctl enable/disable' acts on /etc only. > > It's not a config file, it's the default service. I mean, we could > manage the one in /etc instead, but I don't know that that's that > much better. You could make the argument that the symlink in /lib is > the system maintained software, and therefore is the proper one. Right, if we say that gdm places the link there, I don't see a problem with that. As long as it isn't something the user can change with anything else than (de-)installing rpms, all should be fine. > Honestly, I'd prefer that 'systemctl enable', when called from > spec files, enable under /lib to better define what the system defaults > are. Of course, that might be better handled with the preset code. We should make sure that no host-specific config ends up in /lib or /usr/lib. We like to be able share all that read-only across many hosts, and the enabled/disabled state of a service is probably host-specific and should then only be stored in /etc. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On Mon, Jul 18, 2011 at 23:27, David Michael wrote: > On Mon, Jul 18, 2011 at 5:16 PM, Bill Nottingham wrote: >> Right, but that then causes 'last one wins' behavior among multiple DMs. >> >> I suppose we could use alternatives for this, as much as I dislike it. > > I meant creating that symlink was the replacement for > /etc/sysconfig/desktop, the end-user configuration. Yes, this link will replace the config file. > As for what packages do about their DM service files, I would agree > with letting alternatives manage a default > /lib/systemd/system/display-manager.service symlink, We should not let packages create config files in lib, lib is more for static content from rpms, not really for configuration. For the same reason, 'systemctl enable/disable' acts on /etc only. > but leave the one > in /etc for the users to specify. The link in etc would need to be managed by alternatives, but I'm not sure, if it's really necessary. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On Mon, Jul 18, 2011 at 23:20, Mike McGrath wrote: > On Mon, 18 Jul 2011, Lennart Poettering wrote: >> Hmm? Which ones in fedora can't? Are you suggesting we are shipping >> software that cannot be modified? If so, please explain which one that >> is, since we need to remove it from the distro then. Fedora only >> includess Free Software, and software that cannot be modified would not >> qualify as that. >> > > I'd suggest we're shipping software that doesn't need to be modified, > doesn't need to be "fixed". Saying those daemons need to be fixed is like > saying a pregnant woman need to go to the hospital to be cured. > Pregnancy and /etc/sysconfig are perfectly natural and healthy. Pregnant > women and /etc/sysconfig both have perfectly valid use cases and do not > need to be "fixed" :) Most pregnancies last ~40 weeks. If that takes much longer it needs to be fixed. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On Mon, Jul 18, 2011 at 21:59, Tom Lane wrote: > Lennart Poettering writes: >> On Mon, 18.07.11 15:34, Tom Lane (t...@redhat.com) wrote: >>> Well, if they didn't need fixed before, they'll certainly need fixed >>> when you make them start keeping their configuration info someplace else >>> than /etc/sysconfig. This proposal sounds more like "wait, systemd has >>> not yet broken everything in sight, how can we solve that problem?" >>> than like something that will actually improve matters for anyone. > >> What does systemd break in this regard? > > There's a big difference between "a daemon might not need /etc/sysconfig > anymore once it's been fully integrated into the systemd world" and > "let's deprecate /etc/sysconfig and force packages to stop using it". > Maybe you meant the first, but it's coming across as the second. The 'force' seems to be in your head only. :) We are just communicating that /etc/sysconfig should be phased out, and no new work should be based on it. It should be seen as legacy. Many basic configurations formerly in /etc/sysconfig we have already move to proper /etc config files, and we might continue to do so. /etc/sysconfig is a hack and a pretty bad idea in the first place. Stuff should get native configurations as much as possible, not distro-specific configs. Some day /etc/sysconfig should be almost empty, and then we will see what to do about it, but that might take a very long time, until then there is no need to rush anything. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On Mon, Jul 18, 2011 at 21:45, Adam Miller wrote: > On Mon, Jul 18, 2011 at 09:16:13PM +0200, Lennart Poettering wrote: > >> Hmm? Which ones in fedora can't? Are you suggesting we are shipping >> software that cannot be modified? If so, please explain which one that >> is, since we need to remove it from the distro then. Fedora only >> includess Free Software, and software that cannot be modified would not >> qualify as that. >> >> Lennart > > > What about /etc/sysconfig/network and /etc/sysconfig/network-scripts/ > ... where would be a more appropriate location for those? Not saying > there isn't one, just wondering what the logical progression would be > since that's not really a daemon so much a munge of scripts and config > files that handle network bits... similar question for others like that > which have "service" entries in /etc/init.d/ but aren't actually daemons. There are no clear plans. If someone would come up with a unified network interface config format all distros could use, it would go into some new top-level dir in /etc and not in /etc/sysconfig. Until that happens we will surely continue to use it, but look at it as 'inherited' and not something to extend or base future work on. What we have today is /etc/NetworkManager/system-connections/, but that probably doesn't solve that problem. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [systemd-devel] systemd - move /selinux to /sys/fs/selinux - maybe remove /srv ?
On Sat, Apr 30, 2011 at 02:54, Lennart Poettering wrote: > On Fri, 29.04.11 17:46, Greg KH (g...@kroah.com) wrote: > >> > > I think /srv actually makes a lot of sense. Probably not so much on the >> > > desktop, but the boundaries are blurry, and I see no reason to set >> > > things up differently in this respect between servers and desktops. I >> > > see little benefit in removing this directory. >> > > >> > I think moving /selinux is a bit more complicated then just a simple >> > kernel change. We have libselinux changes, Lots of tools have learned >> > over the years the path of /selinux and lots of users know about it. >> > >> > I am willing to work towards the goal of moving /selinux, but I might >> > end up with a symbolic link if we can not fix all of the problems. >> >> A symbolic link from /selinux to point at /sys/fs/selinux/ is a good >> idea to help people migrate. The startup tools should be able to create >> this if /sys/fs/selinux/ is not present, right? > > This is not necessarily easy to do actually, since for upgraded systems > /selinux needs to be an actual directory in the rootfs to be useful as > mount points. At boot time the rootfs is read-only, hence removing the > dir then and turning it into a symlink is difficult. > > However, we can use the same approach as we did for moving /var/run to > /run: on new installs create it as a symlink and on upgrades simply make > it a bind mount. > > For the long run we could also add %post scripts to filesystem.rpm which > moves away the old /selinux, and recreates it as symlink. Unfortunately > that cannot be done completely atomic, but that property is not really > necessary here anyway I think. > > So, yeah, it isn't super-pretty doing this move, but we can handle it > more or less exactly like the /var/run → /run move. Sounds all fine. I think we should get the kernel patch merged as soon as possible. It will not harm anything if we don't use it now, and continue to use /selinux as long as needed. But it will definitely help solving the chicken egg problem when we are ready to do the switch. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
