Re: RFC: OpenRC as Init System for Debian
On Fri, May 11, 2012 at 12:07:55PM +0200, Jean-Christophe Dubacq wrote: BTW, for standard workstations, there is less and less need to change things in /etc. My current quota is 1346 files in /etc for about 30 of them with local changes. This is quite a bad signal/noise ratio. Well, a standard workstation has many configuration changes I would say, but these changes are all user settings for their WM/DM or application configuration like pidgin or audacious that reside in /home/user. But if you don’t configure files in /etc, why is it a problem if you have many files in /etc? Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | signature.asc Description: Digital signature
Re: RFC: OpenRC as Init System for Debian
On Mon, May 07, 2012 at 03:30:11PM +0100, Ben Hutchings wrote: (lots of options, you get to keep the pieces when they break), but some of us are trying to make Debian better than that. We don't need more half-assed options, we need a solution. Well, it seems we have a problem to define what is „better”. Without this definition we won’t get the right solution. I prefer several half-assed options I can choose from instead of having one solution I don’t like and I can’t change. Then I can use Windows again. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | signature.asc Description: Digital signature
Re: RFC: OpenRC as Init System for Debian
On Sun, Apr 29, 2012 at 10:33:16PM +0900, Miles Bader wrote: Isn't mounting filesystems, which can depend on the network, part of the boot process? Yes, but how do you check if the network is configured and operational? - when the link is up? - when the IP address is configured (how do you check this with IPv6?)? What are you doing if more than one IP address is configured for this NIC or more than one NIC is available? - when the switch accepts traffic on the port you are connected to? - when the router/firewall accepts traffic from your IP address? No event based init system will solve these problems when you have dependencies outside the box you are booting. The local admin has to check if all timings are right and must adjust them if they are not fitting. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: A few observations about systemd
On Thu, Mar 15, 2012 at 01:24:40PM +0100, Josselin Mouette wrote: When it starts to be the case because kFreeBSD doesn’t have a modern init system available, will you reconsider? If I don’t want to support it, I will reconsider, if I will stay in Debian, because Debian is *not* a Linux-only distribution. I can switch to a Linux-only distribution like Ubuntu and support the „cool” things available only in Linux. Okay, I am not a DD, but as a long-time user I have to make the same decisions. If I want „cool” Linux things, then I don’t use a distribution which is proud to be a cross-platform distribution. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | smime.p7s Description: S/MIME cryptographic signature
Re: A few observations about systemd
On Thu, Mar 15, 2012 at 02:10:29PM +0100, Marco d'Itri wrote: On Mar 15, Stephan Seitz stse+deb...@fsing.rootsland.net wrote: Okay, I am not a DD, This pretty much explains why you are not qualified to partecipate to this discussion. You do not seem to be interested in having users, do you? How far will you come without them? Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: upstart: please update to latest upstream version
On Wed, Feb 22, 2012 at 03:24:47PM +0200, Riku Voipio wrote: I have. Not on debian, but on debianish system with dash. And the result was that shellscripts are indeed the bottleneck. We still did convert to I don’t doubt it, but the question is, who cares if the boot process takes a little bit longer? The desktop users I know are fetching their coffee while the system is booting. The modern servers with e.g. RAID controllers are needing much more time from power-on to the grub screen than from grub screen to getty prompt. So while shellscripts may have maintenance issues, I don’t think performance issues are a problem. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | smime.p7s Description: S/MIME cryptographic signature
Re: upstart: please update to latest upstream version
On Thu, Feb 23, 2012 at 01:18:41AM +1100, Russell Coker wrote: Desktop users have a variety of different ways of using systems. Some people like my parents turn their computer on when they are about to use it and watch it boot. It doesn't hurt to have a desktop system boot quickly while unattended but the attended boot times are annoying. Well, my mother is sitting next to her computer as well while it is booting. But she has enough patience to wait. It only takes about a minute at most. I think I waisted more time at bus or train stations. While there are a variety of problems we have to concentrate on the ones that we can solve. True, but the question is: does the new system solves more problems than it creates? And are the solved problems worth the disadvantages? For a faster boot process? Also as has been previously noted there is the case of virtual machines which have no BIOS delays etc. It would be nice to be able to reboot a virtual machine providing a service so quickly that the users barely notice the downtime. In my experience VMs are booting faster than their hardware pendants. I have some system in VMs for testing purposes, and they are booting faster than the real systems. As I said, if you can save some seconds without breaking things, fine. But for now we don’t have any numbers if the majority of Debian users wants to take the risk or are concerned about some saved seconds. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | smime.p7s Description: S/MIME cryptographic signature
Re: upstart: please update to latest upstream version
On Wed, Feb 22, 2012 at 03:09:51PM +, Ben Hutchings wrote: The desktop users I know are fetching their coffee while the system is booting. What if they have to reboot in the middle of the day due to a kernel upgrade? Then they are taking a coffee break or they wait until they haved finished their work and switch off their system anyway. Or they clean up their desk. Or they do some paper work. We are talking about a minute or so. When they are annoyed, it is not because of the reboot time but because they have to save and close all their applications. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: from / to /usr/: a summary
On Thu, Dec 29, 2011 at 05:36:40PM -0800, Josh Triplett wrote: top-level directories would look after a move from / to /usr. Also, the FHS says nothing about the current approach of overriding files in /usr with files in /etc, which allows packages to stop shipping configuration files in /etc that just consist of the default settings. Every package which will accept a configuration file in /etc should ship such a file in /etc, even if it contains only comments. In this way, you know the name(s) of the configuration file(s) and the subdirectory in /etc where they belong. such as /bin, /sbin, /lib, /lib32, /lib64, and so on. However, consolidating all the package-managed bits in /usr would make it entirely sensible to share /usr as a single consistent pile of packaged bits. And where do you want to put the package information which are currently in /var? They do not belong to /usr. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: from / to /usr/: a summary
On Tue, Dec 27, 2011 at 08:54:29AM +0100, Josselin Mouette wrote: Le mardi 27 décembre 2011 à 08:53 +0100, Josselin Mouette a écrit : Le lundi 26 décembre 2011 à 17:08 -0800, Steve Langasek a écrit : If someone would give even *one* example where something legitimately needed by a udev rule could not be moved from /usr to / without breaking interfaces or otherwise complicating matters, then that would be worth discussing. Grah. I mean introducing a udev rule that calls a D-Bus service, of course. And which D-Bus service has to be called at a early boot stage, that it can’t wait until we are leaving single user mode? Udev doesn’t seem to have a trigger database where rules that are not able to run now can insert information, so that udev can execute these rules if they can be run. But this is a bug in udev, not a reason to force people to reconfigure their systems. Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: from / to /usr/: a summary
On Sat, Dec 24, 2011 at 08:17:25PM -0800, Josh Triplett wrote: Debian systems without an initramfs already represent an uncommon case; Are you sure about this? How many server systems have/need an initramfs (think about VMs like XEN DomU)? How many of them are using the big Debian kernel instead of their own with certain options turned on/off (e.g. without IPv6, with certain iptables filters, with HyperV support)? All admins I know have at least some servers with custom kernels (in the past it was said, to build your firewall/server kernels without module support, so that no rootkit module could be loaded). Most of these admins have /usr separated from /. Should all these admins start repartitioning their systems or fiddle with initramfs? We can do this with new systems, yes, but not with the old ones. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: from / to /usr/: a summary
On Wed, Dec 21, 2011 at 09:55:23PM +1100, Russell Coker wrote: The harm is if it takes us extra development time because other distributions don't support it, provide configuration options for it, or test it. Well, this happens with other things as well. There was a time, when Debian was the test platform for XFree86 on other platforms besides x86, because upstream didn’t care for them. Today Debian has still a lot of CPU architectures and has to spent time debugging different programs because upstream does not care for Sparc or ARM. The strict licence politics of Debian are no time savers as well. So your argument can not really be an excuse. Nowadays 100G disks are small by laptop standards and for desktops 1TB is about the smallest that anyone would buy. I know a lot of new desktop systems with 300G, 500G or 750G. And it many cases people don’t know what to do with this space. Finally there has been development of OS technology such as a tmpfs for /dev and the recent addition to Testing and Unstable of a tmpfs for /run which reduces the use of the root filesystem. I don’t really believe this. An old tar archive of /dev is about 670k, /run is a symlink to /var/run, and /var is a different partition of course. Things have changed a lot since the FSSTD first came out. True, but / as emergency system is still a valid reason. That’s why I keep / and /boot outside LVM, so that I can repair/rename/change the LVM system. I did this more than once. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
On Fri, Dec 16, 2011 at 11:52:49AM +, Simon McVittie wrote: I used to have a separate /, /usr and /home on my own machines, but I've given up on that; in practice I never got the size estimates right (e.g. /usr was large enough, but then I wanted to try vegastrike, and life's too short to spend time booting in single-user mode and resizing LVs. Well, while I had such problems, disk space today is so big, that I don’t have the problems anymore. Besides I always want to have separate partitions, so that full partitions (especial user writeable partitions) will not affect the system to much. So I have the following partitions: - /boot (single partition) - / (single partition) - /var (LVM) with a link from /var/tmp to /tmp - /tmp (LVM or tmpfs) - /usr (LVM) - /home (LVM) Sometimes othere partitions are added: - /usr/local (LVM) - /opt (LVM) - different partitions under /var, e.g. for squid, news, databases Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: from / to /usr/: a summary
On Thu, Dec 08, 2011 at 08:34:03PM +, Simon McVittie wrote: On Thu, 08 Dec 2011 at 21:14:05 +0100, Iustin Pop wrote: Please excuse me if I misunderstand things, but there was no information about this in the previous thread: why would gnome _ever_ care when /usr is mounted? For GNOME read system services which GNOME depends on, presumably. Such services should not be started in the early boot stage. And when the system switches to runlevel 2, /usr is mounted. So, this is no excuse. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: from / to /usr/: a summary
On Fri, Dec 09, 2011 at 08:21:30AM +0100, Goswin von Brederlow wrote: As I mentioned I have a bug open (in the grml bug tracker) about providing a grml.deb. That would install an image in /boot and add itself to the bootloader. The small grml image is more like 180MB than 25-50MB but it is a verry good rescue system. And harddisk space is usualy cheap. Maybe, but none of my systems have such a big /boot partition. Older systems have about 50MB, newer systems about 150MB. More is not needed. And do you know why this will not change in the next time? Because I can upgrade Debian from one release to another without reinstalling everything. This is one of the main reasons why I use Debian. If you wish to through this great advantage away because of crappy software, fine. But be prepared that you will lose people. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: Red Hat is moving from / to /usr/
On Thu, Dec 08, 2011 at 10:25:07AM +0100, Goswin von Brederlow wrote: I guess mounting /usr is no more complicated than mounting / in initramfs. Finding out what modules and software is needed for that should be the same code as for /. That depends. I have some systems where all file systems except /boot are encrypted. Since I don’t use Debian kernels and initramfs, I created a small one myself to ask for the /-partition password. Now I would have to put the whole LVM stuff into it, because /usr is on a LVM (/ is not). So it is more complicated. One more reason to get away from udev. :) Yes, I think too, that udev sucks. Instead of merging / and /usr, udev should be enhanced to support runlevels (at least the difference between the early boot stage / single user and the multiuser mode). There is no need to configure the sound card mixer at the early boot stage, and so forcing the user to have /usr on the /-partition. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: Red Hat is moving from / to /usr/
On Wed, Dec 07, 2011 at 11:34:34AM +0100, Marco d'Itri wrote: Actually, Red Hat's goal *is* to support a separate /usr, they just want to have the initramfs mount it. But as was seen in the last discussion, not everyone *has* an initramfs, because it is not needed in many cases or sometimes even not supported on the platform. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: Red Hat is moving from / to /usr/
On Wed, Dec 07, 2011 at 01:11:56PM +0100, Marco d'Itri wrote: On Dec 07, Stephan Seitz stse+deb...@fsing.rootsland.net wrote: But as was seen in the last discussion, not everyone *has* an initramfs, because it is not needed in many cases or sometimes even not supported on the platform. And as was seen, most of these setups can be modified to support this scheme. Yes, but by the admin, not by Debian, and the admin may not be interested in adding a new layer of possible failures, because it works. But still, this does not change the original question: how will we deal with these significant upstream changes in many important packages. Well, I think we should do the same we are doing with other packages whose upstream uses thinks we don’t want (e.g. /opt or non-free files): we patch it so that it fits the Debian way. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: Red Hat is moving from / to /usr/
On Wed, Dec 07, 2011 at 01:44:28PM +0100, Marco d'Itri wrote: On Dec 07, Stephan Seitz stse+deb...@fsing.rootsland.net wrote: Yes, but by the admin, not by Debian, and the admin may not be interested in adding a new layer of possible failures, because it works. And other admins may be interested in the important features which everything-in-usr supports. Who is going to win? If this is the future way and the way the developer want to go, then the way will succeed in time, but as Goswin said, it will take time. The admins who think the new way is bad will not change their systems. New admins may think otherwise, and if the old server will be replaced, they change the system to the new way. Of course, Redhat admins can be forced to change if they need the new version for their systems, but at least Debian does not work this way. Well, I think we should do the same we are doing with other packages whose upstream uses thinks we don’t want (e.g. /opt or non-free files): we patch it so that it fits the Debian way. This may not be practical in the long run, or even possible. Yes, this may happen, but I think for about ten years we have to support both ways as best as we can. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: Re: / vs. /usr vs. fsck(8)
On Wed, Oct 12, 2011 at 08:22:09PM -0700, Josh Triplett wrote: Other than tradition, for what reason do you put /usr on a different filesystem? - I think that the probability that defective hard drive sectors will hit a small partition is less. So your „repair partition” will probably boot at least in emergency mode with more tools than any initramfs. I think that small file systems are less error-prone as well. - Rescue DVDs may not support modern file systems because of older kernels. Here /usr was reiserfs for years, then switched to ext3, new systems have ext4 now. But / was ext2 for a long time (good enough for small partitions), now it has ext3. So it can always be repaired with a rescue DVD. So I am not really interested in making the important boot/repair partition bigger than necessary. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: / vs. /usr vs. fsck(8)
On Thu, Oct 13, 2011 at 04:20:33PM +0200, Marco d'Itri wrote: On Oct 13, Stephan Seitz stse+deb...@fsing.rootsland.net wrote: - I think that the probability that defective hard drive sectors will hit a small partition is less. So your „repair partition” will probably boot at least in emergency mode with more tools than any initramfs. I can't see which tools help you if the disk is phisically broken... If the disk is completely broken, you can’t do anything. But dd_rescue is in /bin, so you can get an image of a partition except for the faulty sectors. I think that small file systems are less error-prone as well. Actually this is a good argument for keeping everything in /usr and then mounting it read only. Maybe, but you can already keep /usr read-only. - Rescue DVDs may not support modern file systems because of older kernels. Not a very compelling reason: if you use an unusual/recent file system, spend two minutes burning an appropriate rescue CD for it. While the burning may take two minutes, it takes much more time to change an existing CD. I tried to change Knoppix some years ago. Thank you, I prefer to use the existing DVDs. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: / vs. /usr vs. fsck(8)
On Wed, Oct 12, 2011 at 09:24:33PM +0200, Marco d'Itri wrote: The Debian initramfs of my sid system is 10 MB, while the one from my My / (testing) is 193M, so I guess, I have much more „emergency” programs available than you. The last time I was trapped within a initramfs, the available programs were useless for me, so I booted with a Knoppix DVD. Getting all the programs in the initramfs would probably make it bigger than my /boot. Beside the initramfs is not a normal partition you can mount with a rescue DVD. So a broken initramfs is harder to fix. I don’t see any advantage in mixing / and /usr. I still do not believe that portability is an issue, and please remember that this would not force people to use an initramfs unless they want to keep /usr on a standalone file system. Most of my systems don’t use initramfs and have / and /usr on different file systems. I am no interested in changing this good tradition. So please don’t break other people’s setup. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: A few observations about systemd
On Sun, Jul 24, 2011 at 09:59:40PM +0200, Wouter Verhelst wrote: That this is not particularly useful is not specific to any init implementation. I hate 'ENABLED=' configuration options with a passion. They do not make *any* sense, even init.d has a documented (and what's They do in packages that ships daemons and client tools. saslauthd, smartd or hddtemp are examples for such useful flags. more, actually *working*) implementation of not starting daemons at boot. It's called 'remove the *** symlink'. Editing /etc/runlevel.conf is easy as well. But I still prefer the good old „exit 0” version. And talking with other people, this seems to be far easier to remember if they want to revert the change. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: A few observations about systemd
On Fri, Jul 22, 2011 at 05:09:11PM +0200, Michael Biebl wrote: Configuration file for the daemon is /etc/default/rsyslog: The canonical configuration file for the rsyslog daemon is /etc/rsyslog.conf. Yes, but it doesn’t allow you to change start options of the daemon itself. include that via EnvironmentFile=/etc/foo/bar [1]. If it is avoidable, you shouldn't do that though, as /etc/default files are Debian specific and one aim of systemd is, that unit files are usable cross-distro. I don’t know if files in /etc/default are Debian specific ones, but sometimes you need to change start parameters of the daemon. One example is sasldauth. If you have postfix in a chroot environemnt (standard Debian), you need to change the parameter for the named socket. So you need a configuration file at least for certain daemons to change options for the daemon start. A lot of those /etc/default files have a ENABLED=YES flags, which are not particularly useful with systemd, as systemd provides proper mechanisms to enable/disable services in a convenient way. Well, that is fine. I often disable a service by putting a „exit 0” in its init script, if I don’t want to always run this service. But why are the unit files not configuration files to begin with like init scripts? In my eyes they all belong in /etc. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: A few observations about systemd
On Thu, Jul 21, 2011 at 11:37:48PM +0200, Josselin Mouette wrote: Le jeudi 21 juillet 2011 à 20:01 +0200, Stephan Seitz a écrit : So, since you don’t need it, other people don’t need it either? No, since I don’t need it, I don’t want to be forced to use it. You know, there are some who just want to use their server or desktop, not to spend their time editing files to tune boot ordering. Bullshit. I don’t know any user or administrator of servers or desktops who have network conditions changing so fast that they often need to change network configuration files. Notebook users are different when they often change their locations, but they can use Network Manager if they want (I don’t need it for my notebook). In fact, NM gets pulled in anyway when you install gnome, so you don’t need to manually install it. I don’t care if systemd is part of Debian, so you can choose to install it, like you can choose between sysklogd, syslog-ng and rsyslog. But I don’t think it is worth to replace sysvinit. That’s utter bullshit. There is ZERO point in being able to choose between several init systems. If the technology allows it, it’s fine to Well, in the end there is ZERO point in chosing between different desktop manager or text editors. You are only confusing users. road to disaster. Users expect one init system that works fine, not 3 with different sets of flaws. And sysvinit is working fine. I never had a system not booting because of sysvinit. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: A few observations about systemd
On Fri, Jul 22, 2011 at 10:46:54AM +0200, Josselin Mouette wrote: Le vendredi 22 juillet 2011 à 09:58 +0200, Stephan Seitz a écrit : So, since you don’t need it, other people don’t need it either? No, since I don’t need it, I don’t want to be forced to use it. So you prefer to force your crap onto others, of course. No, others can choose their own beloved package. As I said, the software can be part of Debian as long as someone is maintaining the package. So let systemd be part of Debian, but not as default init system. Maybe it can be used in about five years when all third party software is supporting it. Server or desktop, the hardware and the kernel are entirely event-based now. This is important for the network, and it is even more important Why? for the boot system. It’s not a question of changing configuration files or whatnot, it’s a question of having it working, and working reliably. Strang, for me it *is* working reliably. features. An init system is not something for the user to see, it should just do the job properly. This will only work if you don’t support third party software. As long as a user can (or must) install other daemon software he has to work with the init system. Now you can guess if the user will find more documentation about integrating the new service with sysvinit or systemd. And sysvinit is working fine. I never had a system not booting because of sysvinit. That’s because init scripts are full of hacks to work around its deficiencies, thanks to tireless tuning work from the maintainers. And even with these hacks, you can always meet a condition (hardware combination, complex partitioning scheme, network configuration) for which it will not work, or - even worse - work randomly. Maybe but it is working for me and for all people I know. How many people are having problems that it is worth the trouble of changing? Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: A few observations about systemd
On Fri, Jul 22, 2011 at 02:59:09PM +0200, Tollef Fog Heen wrote: (Ignoring the kFreeBSD side of things for a bit): Why? As others have pointed out, systemd uses sysvinit scripts just fine. Well, then why don’t we put systemd in testing as alternate init system and release it as alternate init system in wheezy? Those maintainers who want to write unit files in addition to init scripts can do this. In wheezy + 1 we can use systemd as default init with the requisition to still support init scripts for maintainers who don’t want to switch to unit files or third party software. Of course, if we decide that systemd has to run on kfreebsd as well before we change the default init, then the migration will last longer. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: A few observations about systemd
On Fri, Jul 22, 2011 at 04:24:33PM +0200, Michael Biebl wrote: We already have systemd in unstable (and soon testing) and even a handful of packages shipping native systemd service files. The most prominent ones are probably rsyslog, dbus, udev and network-manager. Indeed, rsyslog has a service file. But how would I configure it? /etc/init.d/rsyslog is reading /etc/default/rsyslog. /etc/systemd/system/multi-user.target.wants/rsyslog.service does not read any additional configuration file. Besides rsyslog.service is a symlink to /lib/systemd/system/rsyslog.service, so it is not even a configuration file. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: A few observations about systemd
On Fri, Jul 22, 2011 at 04:49:28PM +0200, Michael Biebl wrote: The configuration file for rsyslog is /etc/rsyslog.conf resp. /etc/rsyslog.d Configuration file for the daemon is /etc/default/rsyslog: # Options for rsyslogd # -m 0 disables ‚MARK’ messages (deprecated, only used in compat mode # 3) # -r enables logging from remote machines (deprecated, only used in # compat mode 3) # -x disables DNS lookups on messages received with -r # -c compatibility mode # See rsyslogd(8) for more details RSYSLOGD_OPTIONS=”-c5” Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: A few observations about systemd
On Thu, Jul 21, 2011 at 05:18:56PM +, Uoti Urpala wrote: There are two primary mistakes you're making here. No, you still don’t understand how Debian works. Debian does *not* always do things that would benefit most of its users. If this was our goal, we would ignore licence problems of any kind and put documentation, firmware, flash and other things back into main. This would help most of our users far more than the switch to systemd. But we don’t do this. So why do you think we should switch to systemd as a default init? I still don’t see the great advantages of systemd. It has some, yes, but how many people are really affected by the problems of our standard init? I’m using Debian for over ten years (server and desktop) and have never had a problem that would make me change sysvinit. I still don’t use insserv and have file-rc installed on all of my systems. I love it when I can disable a service by writing „exit 0” on top of its init script. So why should I want to switch? And yes, I disable NetworkManager on any system as well. I don’t need it. I don’t care if systemd is part of Debian, so you can choose to install it, like you can choose between sysklogd, syslog-ng and rsyslog. But I don’t think it is worth to replace sysvinit. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: ifupdown 0.7~alpha4 in experimental
On Wed, Jun 15, 2011 at 06:52:54PM +0200, Christian Hammers wrote: As a workaround you can already add the following to /etc/network/interfaces to change your fixed address: # Mark this address as still reachable but deprecated as source # address for new outgoing connections: up ip addr change 2001:f00::1234/64 dev eth0 preferred_lft 0 Thanks for your answer. So how do you do the auto configuration? Do you have radvd running or a DHCPv6 server? If I understand correctly, radvd won’t give you DNS servers. How would an interface configuration look like? Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: ifupdown 0.7~alpha4 in experimental
On Thu, Jun 16, 2011 at 11:42:05AM +0100, Edward Allcutt wrote: So how do you do the auto configuration? Do you have radvd running or a DHCPv6 server? If I understand correctly, radvd won’t give you DNS servers. radvd can be configured to provide dns servers, eg. Thanks to you and the others for your information. The client also needs to accept these. Linux (the kernel) keeps track of dns servers advertised in this way but does not update userspace resolvers directly. I recommend installing rdnssd which gets these details from the kernel via a netlink socket and updates /etc/resolv.conf Well, it seems I would need another method for Windows clients. Please let me explain my setup and my intentions: One system is a XEN system with two NICs. DomU is the firewall (one NIC for PPPoE and a Sixxs IPv6 tunnel via aiccu, one NIC for the internal network). It provides a Squid proxy, DNS and DHCPv4 server for guests. Dom0 is my workstation. It only has an IP address on the network bridge to the internal network. My notebook is connected via switch to the internal network. In my IPv4 setup all my systems have fixed private IP addresses. The firewall is NATting the external traffic. Since my provider changes my PPPoE IP address every 24 hours, my external address is not constant. Since IPv6 doesn’t provide NAT, all my systems have now a fixed public IPv6 address. My goal is to shuffle the addresses in my big IPv6 network, so that external systems will always see another IPv6 address. Besides that, guest systems (Windows and Linux) should get IPv4 and IPv6 addresses with all necessary information (Gateway and DNS). IPv4 is covered. So how will I do this? If I install radvd at my firewall (DomU), the fixed IP addresses are already set. So the temporary addresses have to be activated later. Any hints are welcome. Maybe this is the wrong list and the discussion should be moved to debian-user? If yes feel free. I’m reading both lists. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: ifupdown 0.7~alpha4 in experimental
On Wed, Jun 08, 2011 at 05:06:09PM +0300, Andrew O. Shadoura wrote: As some may already have noticed, the new ifupdown revision, 0.7~alpha4 entered experimental, and is successfully built at least on i386 and amd64. Thanks for your work. Does this package support configuring different IPv6 address types (say one fixed address, so you know how to reach the system, and one dynamic address (privacy extension) for outgoing traffic)? If not yet, is this feature planned? Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: some suggestions towards a Debian .desktop policy [Was: Warm up discussion about desktop files]
On Fri, Apr 22, 2011 at 06:05:20PM +0200, Josselin Mouette wrote: You’re missing something. A menu that “shows everything” is unusable. The Debian menu is a very good example of that kind of problem. I think this depends on the number of entries. If you have a high number you’re right. When I used Enlightenment years ago I had sometimes troubles to scroll through certain menu points, because there were so many items. You could solve this problem by creating more submenus (e.g. A B C). Or you can try to show only certain items. Both cases can confuse users (I installed package xy, why can’t I find it in the menu?). I don’t know what XFCE does now, but I use mostly the shell to start applications, because I don’t want to look through to menu only to find out that someone thought I shouldn’t see the application. Happy Eastern! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: some suggestions towards a Debian .desktop policy
On Thu, Apr 21, 2011 at 09:06:45AM +0100, Lars Wirzenius wrote: While we perhaps should make anything possible for our users, unless it requires too effort from us, that does not mean that all users should be confronted with every available option all the time. Having to choose I agree. Would it be possible to have a simple „show all” function in every menu tree that will show all application? Or a second menu tree with all application? I normally start application I know and use from the shell, but I use the menu to look for applications that are installed but are unknown to me. And I had already people in my company who asked me why they didn’t find a certain application in their menu. Well, it was filtered because other people thought they shouldn’t see this application in the environment the users were using. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: network-manager as default? No!
On Fri, Apr 15, 2011 at 03:32:18PM +0200, Josselin Mouette wrote: This was stated in the original proposal: ifupdown is not event-based and does not integrate correctly with modern boot systems. So what? ifupdown is working on most setups without problems with VLANs bonds, or bridges out of the box without unnecessary dependencies and daemons. Beside I am not interested in having my network reconfigured by a stupid daemon finding some „events”. I don’t even use event base boot systems (still using file-rc), because I don’t like the idea. Sticking to this unmaintained piece of software with a design for systems from the 80s only leads to an increasing amount of complexity to This design has not changed much. Even today most systems still have the same configuration as they had for the last ten years. One IP address, one gateway and some DNS servers. The configuration for ifupdown has become easier in the last years as well. In the beginning you had to script your VLAN or bond magic yourself, now there already exists hooks. I certainly don’t mind having N-M in the archives. If someone wish to install it, he should be able to. But I don’t want N-M as part of the base installation and handling my network without me choosing to do so. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: network-manager as default? No!
On Fri, Apr 15, 2011 at 03:23:32PM +0200, Josselin Mouette wrote: NM may be good for laptops, so put it in the laptop task and leave the rest alone in the default installation. And keep the installer unable to do things as widespread as WPA? And keep it unable to generate a proper configuration for laptops? How many systems are needing WLAN for installation? Servers don’t have WLAN, I never have seen a Desktop with WLAN (neither in companies nor private PCs). I only have WLAN in laptops. And since I only have Intel WiFi, d-i never was able to use it because I need non-free firmware (no fault of d-i, mind you, non-free is non-free, which is a part why I don’t like WLAN). But if you think that is so important, put N-M in d-i and activate it if the user wants to use WLAN for installation. But don’t install it if the user doesn’t explicitly ask for it. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: network-manager as default? No!
On Wed, Apr 13, 2011 at 09:47:54PM +0200, Bjørn Mork wrote: protocols. I would have preferred something like some routers do: iface eth0 address .. ipv6address .. I think this is a very good idea, because you don’t have to duplicate bridge configurations. If the configuration looked like this I could live with the fact not being able to (de)activate one part of a dual stack interface. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: network-manager as default? No!
On Fri, Apr 15, 2011 at 08:27:03AM +0200, Josselin Mouette wrote: Since it was completely redesigned, almost from scratch, this doesn’t apply for 0.8. Its system daemon is able to manage connections without anyone logged on, and with a number of features that makes ifupdown look like a baby toy. Maybe, but *I* had never a need for it. I can do my VLAN and bridge configuration with ifupdown. Most PCs of mine don’t have WLAN cards, so I don’t need NM with running wpasupplicant. And those PCs have a static network configuration. NM may be good for laptops, so put it in the laptop task and leave the rest alone in the default installation. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: network-manager as default? No!
On Wed, Apr 13, 2011 at 11:11:27AM +0200, sean finney wrote: Did i miss the part where somebody explained what the user benefit of having network-manager on a server was? (apart from then it's the same as your desktop[1], anyway). I don’t even know why NM should be on a normal desktop. My first (and last) contact with NM was not a good one. I was doing a remote upgrade of a desktop and suddenly the system was unreachable. After a reboot it worked, but shortly the system was unreachable again. Then I noticed that the default gateway was missing. The desktop didn’t have a configured eth0, but two configured vlan interfaces. NM thought, hey let’s configure eth0, and tried to configure eth0 via DHCP and deleted the default gateway. Since then, the first thing I do is to disable this crap. Besides I don’t have any desktop with WLAN interface. So ifupdown is more than enough to configure the network. Some people say that NM is good with WLAN. Maybe. Since I don’t touch NM again, I always used ifupdown and wpasupplicant with success. But I rarely use WLAN. If NM is really good with WLAN it should only be part of the laptop task and never touch cable networks. The only thing that I miss from ifupdown (and I configured bonds, bridges and vlans) is a good IPv6 support. I can’t separately activate or deactivate IPv4 or IPv6 parts of an interface. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: bonding and bridging
In debian.devel.user Guus Sliepen [EMAIL PROTECTED] wrote: Add the bonding module to /etc/modules, so that bond0 exists when the network interfaces are brought up. Then you can do something like: iface bond0 inet static address 0.0.0.0 netmask 0.0.0.0 slaves eth0 eth1 I would use: iface bond0 inet manual slaves eth0 eth1 pre-up /sbin/ifconfig bond0 up Without the pre-up line bond0 will not be activated (Etch). Shade and sweet water! Stephan -- | consistec Engineering Consulting GmbH Saarbrücken | | WWW: http://www.consistec.de/ Kontakt: [EMAIL PROTECTED] | | Tel.: +49 681 / 95904400 Fax: +49 681 / 95904411 | | Registergericht: Amtsgericht SaarbrückenRegisterblatt: HRB12003 | | Geschäftsführer: Dr. Thomas Sinnwell, Volker Leiendecker, Stefan Sinnwell | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
