[arch-general] libsystemd to systemd
Hello, Last update (10 minutes ago) asked me if y want switch from libsystemd to core/systemd. I agreed, and on next reboot, networkmanager was not started automaticly from rc.conf. it work well if y start it by hand (/etc/rc.d/networkmanager start). can you please help me to get it started at boot again ? -- Mathieu R.
On August 31, 2012 02:06:56 AM Mathieu R. wrote:
Last update (10 minutes ago) asked me if y want switch from libsystemd to core/systemd. I agreed, and on next reboot, networkmanager was not started automaticly from rc.conf. it work well if y start it by hand (/etc/rc.d/networkmanager start).
Does it work if you use systemctl to enable it on boot instead? systemctl enable NetworkManager.service
On 08/30/2012 07:30 PM, baker.stephen.e@gmail.com wrote:
On August 31, 2012 02:06:56 AM Mathieu R. wrote:
Last update (10 minutes ago) asked me if y want switch from libsystemd to core/systemd. I agreed, and on next reboot, networkmanager was not started automaticly from rc.conf. it work well if y start it by hand (/etc/rc.d/networkmanager start).
Does it work if you use systemctl to enable it on boot instead? systemctl enable NetworkManager.service
Mathieu, Are you using initscripts or systemd?
2012/8/31 Matthew Monaco <dgbaley27@0x01b.net>:
On 08/30/2012 07:30 PM, baker.stephen.e@gmail.com wrote:
On August 31, 2012 02:06:56 AM Mathieu R. wrote:
Last update (10 minutes ago) asked me if y want switch from libsystemd to core/systemd. I agreed, and on next reboot, networkmanager was not started automaticly from rc.conf. it work well if y start it by hand (/etc/rc.d/networkmanager start).
Does it work if you use systemctl to enable it on boot instead? systemctl enable NetworkManager.service
Mathieu,
Are you using initscripts or systemd?
i had a working answer on forums, there : https://bbs.archlinux.org/viewtopic.php?pid=1154017#p1154017 thank you. -- Mathieu R.
On Fri, 2012-08-31 at 09:30 +0200, Mathieu R. wrote:
2012/8/31 Matthew Monaco <dgbaley27@0x01b.net>:
On 08/30/2012 07:30 PM, baker.stephen.e@gmail.com wrote:
On August 31, 2012 02:06:56 AM Mathieu R. wrote:
Last update (10 minutes ago) asked me if y want switch from libsystemd to core/systemd. I agreed, and on next reboot, networkmanager was not started automaticly from rc.conf. it work well if y start it by hand (/etc/rc.d/networkmanager start).
Does it work if you use systemctl to enable it on boot instead? systemctl enable NetworkManager.service
Mathieu,
Are you using initscripts or systemd?
i had a working answer on forums, there : https://bbs.archlinux.org/viewtopic.php?pid=1154017#p1154017 thank you.
# pacman -Syu :: Replace libsystemd with core/systemd? [Y/n] # grep DAEMONS /etc/rc.conf DAEMONS=(69switch_xorg.conf hwclock syslog-ng !network !netfs crond acpid dbus networkmanager rtirq) I don't understand "Eliminate the daemons one by one from rc.conf. Start with dbus, which systemd handles very well without any action from you at all". How can I upgrade, but keep a running system? "69switch_xorg.conf" e.g. is a script that switch between 2 xorg.conf regarding to the kernel I boot. If I remove all "daemons" from rc.conf, have I then to set up systemd? Can I simply say "no" regarding to :: Replace libsystemd with core/systemd? [Y/n] n :: Replace systemd-tools with core/systemd? [Y/n] n but say yes regarding to Targets (16): cracklib-2.8.19-1 filesystem-2012.8-1 glibc-2.16.0-4 gnutls-3.1.0-1 imagemagick-6.7.9.2-1 initscripts-2012.08.3-2 khrplatform-devel-8.0.4-3 lib32-gdk-pixbuf2-2.26.3-1 lib32-glibc-2.16.0-4 libdrm-2.4.39-1 libegl-8.0.4-3 libgbm-8.0.4-3 libglapi-8.0.4-3 libwebkit3-1.8.3-1 mesa-8.0.4-3 rpcbind-0.2.0-9 ? I can't see any information at http://www.archlinux.org/ or https://www.archlinux.de/. I'm confused. Regards, Ralf
On Fri, Aug 31, 2012 at 11:04 AM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
I don't understand "Eliminate the daemons one by one from rc.conf. Start with dbus, which systemd handles very well without any action from you at all". How can I upgrade, but keep a running system?
I believe that post was making the assumption that you switched to systemd. If you do not wish to switch to systemd yet, then no action is required. See [0] for some details.
"69switch_xorg.conf" e.g. is a script that switch between 2 xorg.conf regarding to the kernel I boot. If I remove all "daemons" from rc.conf, have I then to set up systemd?
In order to use systemd (after the upgrade), either append init=/bin/systemd to your kernel commandline or install systemd-sysvcompat (which will conflict with sysvinit). If you do not, then you'll stay with initscripts.
Can I simply say "no" regarding to
:: Replace libsystemd with core/systemd? [Y/n] n :: Replace systemd-tools with core/systemd? [Y/n] n
but say yes regarding to
No, partial upgrades will not work well (as always). Though, as I mentioned, saying "yes" does not really mean anything unless you actively switch on systemd. HTH, Tom [0]: <http://mailman.archlinux.org/pipermail/arch-dev-public/2012-August/023469.html>
Thank you Tom :) On Fri, 2012-08-31 at 11:14 +0200, Tom Gundersen wrote:
If you do not wish to switch to systemd yet, then no action is required. See [0] for some details.
I'm not switching yet. First I'll test it in VBox, but at the moment I don't have time to do it, I need a stable Arch Linux. So I'll backup my current install and then upgrade, without changing anything and hope it still will work. If not I'll restore Arch from the backup. IIUC the OP got issues regarding to networkmanager, while not switching to systemd. However, no big deal since I don't need to upgrade at the moment. I can use my Arch without an upgrade now and do the upgrade later, when I've got time to switch to systemd. I don't like to switch, but I guess it will make my live easier. Regards, Ralf
On Fri, Aug 31, 2012 at 11:24 AM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
IIUC the OP got issues regarding to networkmanager, while not switching to systemd.
For the people not reading the forums: it seems the problem was with the order of daemons in rc.conf, and should be unrelated to systemd. For people not using systemd, this change should really not have any effect at all (you'll just have some extra unused files around). -t
On Fri, 2012-08-31 at 11:34 +0200, Tom Gundersen wrote:
On Fri, Aug 31, 2012 at 11:24 AM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
IIUC the OP got issues regarding to networkmanager, while not switching to systemd.
For the people not reading the forums: it seems the problem was with the order of daemons in rc.conf, and should be unrelated to systemd. For people not using systemd, this change should really not have any effect at all (you'll just have some extra unused files around).
And I didn't understand it/misunderstand it. Ok, now I understand and know what to do :). Regards, Ralf
IIUC the OP got issues regarding to networkmanager, while not switching to systemd.
For the people not reading the forums: it seems the problem was with the order of daemons in rc.conf, and should be unrelated to systemd. For people not using systemd, this change should really not have any effect at all (you'll just have some extra unused files around).
While the cause has been explained I think we are missing the Why or is it How. If dbus was out of order how come it worked under initscripts? Is it because initscripts checks the list and starts dbus early in any case and the init script compatibility over-rid systemds similar behaviour? You've probably answered this but I'm not sure where to look. I tried to check the commits for systemd and libsystemd which is now missing. I assumed they were used a little, if they are unused why are they required, dependencies? -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
On 31/08/12 20:44, Kevin Chadwick wrote:
IIUC the OP got issues regarding to networkmanager, while not switching to systemd.
For the people not reading the forums: it seems the problem was with the order of daemons in rc.conf, and should be unrelated to systemd. For people not using systemd, this change should really not have any effect at all (you'll just have some extra unused files around).
While the cause has been explained I think we are missing the Why or is it How.
If dbus was out of order how come it worked under initscripts? Is it because initscripts checks the list and starts dbus early in any case and the init script compatibility over-rid systemds similar behaviour?
He is not using systemd at all... So the upgrade of systemd is a red-herring here. Allan
On Fri, Aug 31, 2012 at 12:44 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
While the cause has been explained I think we are missing the Why or is it How.
If dbus was out of order how come it worked under initscripts?
I have honestly no idea why the setup used to work (it never should have), and what made it stop working (nothing should have changed). Notice that the OP is still using initscripts. My best guess is there was a race and somehow something sped-up or slowed down to make it trigger.
Is it because initscripts checks the list and starts dbus early in any case and the init script compatibility over-rid systemds similar behaviour?
Under initscripts all daemons are started exactly in the order given in the DAEMONS array. With the exception of udevd which is started unconditionally early on in rc.sysinit and does not have an rc script. Under systemd the ordering is given in each of the service files, dbus comes with its own service/socket files so that should be started correctly (the socket is started very early on so it is always available from the point of view of all the other daemons). If you use systemd with the initscripts compatibility layer (i.e., you have some rc scripts that don't yet have equivalent native systemd service files), then the ordering of when to start them is taken from the DAEMONS array as in initscripts. Notice however, that this is the last fallback, and the ordering information given in any available native service files take precedence. People are grumbling about this compatibility layer, and I might change/remove it at some point. The reason I still have not ripped it out is that I like the fact that your system will "just work" as before if you add init=/bin/systemd to the kernel command line. Without the compatibility layer you'd have to also enable the relevant services (I guess that's not too much to ask though...).
I assumed they were used a little, if they are unused why are they required, dependencies?
Not entirely sure what you are asking. systemd-tools used to be a dependency of initscripts (it is used all over the place), now systemd-tools was merged into systemd, so systemd is a dependency of initscripts. Does that answer your question?
While the cause has been explained I think we are missing the Why or is it How.
If dbus was out of order how come it worked under initscripts?
I have honestly no idea why the setup used to work (it never should have), and what made it stop working (nothing should have changed). Notice that the OP is still using initscripts. My best guess is there was a race and somehow something sped-up or slowed down to make it trigger.
And this is yet another example how initscripts are broken. I had a friend whose GDM was not coming up because it was starting too fast after dbus. As a last resort we rearranged the DAEMONS and moved gdm as the last daemon (after NM etc) and it magically started to work. With systemd you could start gdm as fast as you want and systemd would make sure its dependencies are met, either by starting them first, or buffering the socket/dbus calls. -- damjan
On Fri, 2012-08-31 at 13:51 +0200, Damjan Georgievski wrote:
While the cause has been explained I think we are missing the Why or is it How.
If dbus was out of order how come it worked under initscripts?
I have honestly no idea why the setup used to work (it never should have), and what made it stop working (nothing should have changed). Notice that the OP is still using initscripts. My best guess is there was a race and somehow something sped-up or slowed down to make it trigger.
And this is yet another example how initscripts are broken. I had a friend whose GDM was not coming up because it was starting too fast after dbus. As a last resort we rearranged the DAEMONS and moved gdm as the last daemon (after NM etc) and it magically started to work.
With systemd you could start gdm as fast as you want and systemd would make sure its dependencies are met, either by starting them first, or buffering the socket/dbus calls.
I use GDM too, but it's not in the DAEMONS list. [root@archlinux spinymouse]# grep DAEMONS /etc/rc.conf # DAEMONS DAEMONS=(69switch_xorg.conf hwclock syslog-ng !network !netfs crond acpid dbus networkmanager rtirq) [root@archlinux spinymouse]# pacman -Qi gdm Name : gdm Version : 3.4.1-3 *?*
On Fri, Aug 31, 2012 at 03:30:43PM +0200, Ralf Mardorf wrote:
On Fri, 2012-08-31 at 13:51 +0200, Damjan Georgievski wrote:
And this is yet another example how initscripts are broken. I had a friend whose GDM was not coming up because it was starting too fast after dbus. As a last resort we rearranged the DAEMONS and moved gdm as the last daemon (after NM etc) and it magically started to work. I use GDM too, but it's not in the DAEMONS list.
[root@archlinux spinymouse]# grep DAEMONS /etc/rc.conf # DAEMONS DAEMONS=(69switch_xorg.conf hwclock syslog-ng !network !netfs crond acpid dbus networkmanager rtirq) [root@archlinux spinymouse]# pacman -Qi gdm Name : gdm Version : 3.4.1-3
*?*
You probably use the inittab method https://wiki.archlinux.org/index.php/Display_Manager#inittab_method
On Fri, 2012-08-31 at 20:45 +0530, gt wrote:
On Fri, Aug 31, 2012 at 03:30:43PM +0200, Ralf Mardorf wrote:
On Fri, 2012-08-31 at 13:51 +0200, Damjan Georgievski wrote:
And this is yet another example how initscripts are broken. I had a friend whose GDM was not coming up because it was starting too fast after dbus. As a last resort we rearranged the DAEMONS and moved gdm as the last daemon (after NM etc) and it magically started to work. I use GDM too, but it's not in the DAEMONS list.
[root@archlinux spinymouse]# grep DAEMONS /etc/rc.conf # DAEMONS DAEMONS=(69switch_xorg.conf hwclock syslog-ng !network !netfs crond acpid dbus networkmanager rtirq) [root@archlinux spinymouse]# pacman -Qi gdm Name : gdm Version : 3.4.1-3
*?*
You probably use the inittab method
https://wiki.archlinux.org/index.php/Display_Manager#inittab_method
Correct and startup just takes some seconds not using systemd and I never had issues. However, soon or later I'll switch to systemd. I don't like to discuss this anymore, I don't like to switch, but I guess there's no other choice. IMO it's unfair to claim that initscripts is broken. There might be bugs, but it isn't broken. Some coder(s) have done a good job, but today it sounds like initscripts is something terrible. It is disrespectful not to honor that initscripts is something good, even if there should be something better now. Regards, Ralf
It is disrespectful not to honor that initscripts is something good, even if there should be something better now.
Don't listen, it isn't better, shell is awesome and so are init scripts though a top notch consensus would be good. I can point out multiple errors and wrong assumptions in just the first few paragraphs on the systemd blog link that was posted again recently but I've had enough time wasted on something that I've come to see as likely to fail or get any more distro coverage. I don't think Lennart has much unix admin experience. I'm not saying don't switch, you will get better support for systemd on this list that's for sure. I will give one example. Lennart says come on who connects to sshd more than once a month. I can't believe he's never seen a sshd log with constant pass attempts even though passwords are disabled. Be honest Tom, do you think it is less or more risky timewise for him to switch, right now? -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
On Aug 31, 2012 6:31 PM, "Kevin Chadwick" <ma1l1ists@yahoo.co.uk> wrote:
I will give one example. Lennart says come on who connects to sshd more than once a month. I can't believe he's never seen a sshd log with constant pass attempts even though passwords are disabled.
You are misunderstanding the sshd example.
Be honest Tom, do you think it is less or more risky timewise for him to switch, right now?
We have still not recommended that everyone should switch. The reason is that we are still working on making the transition smoother and making sure all edge-cases are covered. The only thing to keep in mind is that if you rely on something non-standard, it might be worth checking that it still works so we'll know of any problems/blockers as soon as possible. Tom
I will give one example. Lennart says come on who connects to sshd more than once a month. I can't believe he's never seen a sshd log with constant pass attempts even though passwords are disabled.
You are misunderstanding the sshd example.
How? Systemds method would seem more problematic and wasteful to me if you get connections to it a lot. Home connections even get many ssh connection attempts and in any case it would seem to show he has no experience in administration. -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
On Aug 31, 2012 7:47 PM, "Kevin Chadwick" <ma1l1ists@yahoo.co.uk> wrote:
I will give one example. Lennart says come on who connects to sshd
more
than once a month. I can't believe he's never seen a sshd log with constant pass attempts even though passwords are disabled.
You are misunderstanding the sshd example.
How? Systemds method would seem more problematic and wasteful to me if you get connections to it a lot.
The example explicitly only deals with the case where you do not get a lot of connections. E.g. in a private network.
Home connections even get many ssh connection attempts
If you have a pubic IP you'd be better off using the regular service and not the xinet-style one. Tom
On Aug 31, 2012 7:47 PM, "Kevin Chadwick" <ma1l1ists@yahoo.co.uk> wrote:
I will give one example. Lennart says come on who connects to sshd
more
than once a month. I can't believe he's never seen a sshd log with constant pass attempts even though passwords are disabled.
You are misunderstanding the sshd example.
How? Systemds method would seem more problematic and wasteful to me if you get connections to it a lot.
The example explicitly only deals with the case where you do not get a lot of connections. E.g. in a private network.
"And even SSH: as long as nobody wants to contact your machine there is no need to run it, as long as it is then started on the first connection. (And admit it, on most machines where sshd might be listening somebody connects to it only every other month or so.)" Your just making stuff up now to cover his back, which questions many of your many baseless responses simply stating I have shown I don't understand systemd, end of discussion. It is far less likely that ssh is used behind a firewall and there is no mention of this, it is a fact that ssh is primarily used to cross the internet where it will be connected to frequently on any connection as long as it is set to the recommended default port.
Home connections even get many ssh connection attempts
If you have a pubic IP you'd be better off using the regular service and not the xinet-style one.
Tom
The point is that much of his spec like bringing linux together and assumptions are wrong and significant sacrifices for speed bring tiny speed increases. Here's another assumption. "A central part of a system that starts up and maintains services should be process babysitting: it should watch services. Restart them if they shut down." Wrong, few want this feature and respawn and especially baby sitting is not a central feature of 'services' for an init system. On single web server this may be desired and a user installs a small package to do so that has features systemd hasn't and shouldn't have. In most cases it isn't true and if you have redundant services as most do or a secure service, you don't want the service restarted as it may have been exploited, the restart may even enable the exploit, so another server will take over instead. Right, you've got me to waste more time than I wished, so no more. -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
On Sat, Sep 1, 2012 at 2:46 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
On Aug 31, 2012 7:47 PM, "Kevin Chadwick" <ma1l1ists@yahoo.co.uk> wrote:
I will give one example. Lennart says come on who connects to sshd
more
than once a month. I can't believe he's never seen a sshd log with constant pass attempts even though passwords are disabled.
You are misunderstanding the sshd example.
How? Systemds method would seem more problematic and wasteful to me if you get connections to it a lot.
The example explicitly only deals with the case where you do not get a lot of connections. E.g. in a private network.
"And even SSH: as long as nobody wants to contact your machine there is no need to run it, as long as it is then started on the first connection. (And admit it, on most machines where sshd might be listening somebody connects to it only every other month or so.)"
That is close to BS I am afraid - I run several machines where there is a connection in several times a day sometimes even more often.
It is far less likely that ssh is used behind a firewall and there is no mention of this, it is a fact that ssh is primarily used to cross the internet where it will be connected to frequently on any connection as long as it is set to the recommended default port.
My use case includes using sshd behind a firewall - and it far from uncommon!
Home connections even get many ssh connection attempts
If you have a pubic IP you'd be better off using the regular service and not the xinet-style one.
Can't comment on that statement!!!
In most cases it isn't true and if you have redundant services as most do or a secure service, you don't want the service restarted as it may have been exploited, the restart may even enable the exploit, so another server will take over instead.
And the evidence for this is where? -- mike c
On Sat, Sep 1, 2012 at 8:46 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
On Aug 31, 2012 7:47 PM, "Kevin Chadwick" <ma1l1ists@yahoo.co.uk> wrote:
I will give one example. Lennart says come on who connects to sshd
more
than once a month. I can't believe he's never seen a sshd log with constant pass attempts even though passwords are disabled.
You are misunderstanding the sshd example.
How? Systemds method would seem more problematic and wasteful to me if you get connections to it a lot.
The example explicitly only deals with the case where you do not get a lot of connections. E.g. in a private network.
"And even SSH: as long as nobody wants to contact your machine there is no need to run it, as long as it is then started on the first connection. (And admit it, on most machines where sshd might be listening somebody connects to it only every other month or so.)"
Your just making stuff up now to cover his back, which questions many of your many baseless responses simply stating I have shown I don't understand systemd, end of discussion.
It is far less likely that ssh is used behind a firewall and there is no mention of this, it is a fact that ssh is primarily used to cross the internet where it will be connected to frequently on any connection as long as it is set to the recommended default port.
i highly doubt you, Lennart, or anyone else for that matter has any real numbers to support anything being said, so please, spare me. now, IME, both privately and in the numerous IT-based companies i've both worked and/or consulted with ... there are indeed usually MANY servers that happily run sshd all day long, and do not receive connections unless there is a problem. regardless, Lennart's only point was "sshd should only start when someone tries to connect" ... let's not beat around the bush here, mmk? ... and a connection attempt is very different from a connection. if you really want to block the former, then you use something like fwknopd to make the sshd port invisible to everyone except the authorized. i use this on all my servers -- it's fantastic.
Home connections even get many ssh connection attempts
If you have a pubic IP you'd be better off using the regular service and not the xinet-style one.
The point is that much of his spec like bringing linux together and assumptions are wrong and significant sacrifices for speed bring tiny speed increases.
... tell me, have you actually ran systemd yet? hmm ...
Here's another assumption.
"A central part of a system that starts up and maintains services should be process babysitting: it should watch services. Restart them if they shut down."
Wrong, few want this feature and respawn and especially baby sitting is not a central feature of 'services' for an init system.
ehm, of the whopping 3 or so things sysvinit actually DID for you, wasn't respawn one of them? you seem to want an init that does nothing at all -- and since shell is "like teh coolest thing eva .. eva", i suggest writing one in bash! it's not hard, and like i said in the past, i wrote one for LXC based systems that was ~20-30 lines, FULLY replacing sysvinit (well, i used that until systemd started to work nicely ;-)
On single web server this may be desired and a user installs a small package to do so that has features systemd hasn't and shouldn't have.
*yawn*
In most cases it isn't true and if you have redundant services as most do or a secure service, you don't want the service restarted as it may have been exploited, the restart may even enable the exploit, so another server will take over instead.
# systemctl stop <exploited>.service [and optionally] # systemctl disable <exploited>.service ... problem solved?
Right, you've got me to waste more time than I wished, so no more.
nah friend, you did this to yourself -- no one made you do anything. -- C Anthony
On Sat, Sep 1, 2012 at 8:46 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
On Aug 31, 2012 7:47 PM, "Kevin Chadwick" <ma1l1ists@yahoo.co.uk> wrote:
I will give one example. Lennart says come on who connects to sshd
more
than once a month. I can't believe he's never seen a sshd log with constant pass attempts even though passwords are disabled.
You are misunderstanding the sshd example.
How? Systemds method would seem more problematic and wasteful to me if you get connections to it a lot.
The example explicitly only deals with the case where you do not get a lot of connections. E.g. in a private network.
"And even SSH: as long as nobody wants to contact your machine there is no need to run it, as long as it is then started on the first connection. (And admit it, on most machines where sshd might be listening somebody connects to it only every other month or so.)"
Your just making stuff up now to cover his back, which questions many of your many baseless responses simply stating I have shown I don't understand systemd, end of discussion.
It is far less likely that ssh is used behind a firewall and there is no mention of this, it is a fact that ssh is primarily used to cross the internet where it will be connected to frequently on any connection as long as it is set to the recommended default port.
i highly doubt you, Lennart, or anyone else for that matter has any real numbers to support anything being said, so please, spare me.
That would be obvious to anyone with any experience. Show me data that says sshd is used more often behind firewalls. Of course it isn't. What data that there are far more remote hosting than local hosting, of course there is, you shouldn't need data to accept this point. Just check your logs. I'd hope that if you run a daemon, you expect someone to connect to it.
now, IME, both privately and in the numerous IT-based companies i've both worked and/or consulted with ... there are indeed usually MANY servers that happily run sshd all day long, and do not receive connections unless there is a problem.
Are these public facing on the default port as is most cases because in that case you must be looking at auth successes and not failures. Just look up why it is best to use public key and disable passwords. IT-based companies, please do they still suggest ftp for web upload by default.
regardless, Lennart's only point was "sshd should only start when someone tries to connect" ... let's not beat around the bush here, mmk?
... and a connection attempt is very different from a connection. if you really want to block the former, then you use something like fwknopd to make the sshd port invisible to everyone except the authorized. i use this on all my servers -- it's fantastic.
Funny how systemd advocates never seem to get the points. I don't want to block anything, that's what sshd does anyway without adding extra less audited crypto. You realise a server running openssl is more vulnerable to exploits than one without, right? Are you going to miss the point and bring up web code now.
Home connections even get many ssh connection attempts
If you have a pubic IP you'd be better off using the regular service and not the xinet-style one.
The point is that much of his spec like bringing linux together and assumptions are wrong and significant sacrifices for speed bring tiny speed increases.
... tell me, have you actually ran systemd yet? hmm ...
Only on Fedora which takes longer to boot than my arch but that's irrelevant. I think the potential of speed increase has quite clearly been determined to be in the < 3 seconds range ignoring the stupid argument of what if something pauses.
Here's another assumption.
"A central part of a system that starts up and maintains services should be process babysitting: it should watch services. Restart them if they shut down."
Wrong, few want this feature and respawn and especially baby sitting is not a central feature of 'services' for an init system.
ehm, of the whopping 3 or so things sysvinit actually DID for you, wasn't respawn one of them?
That's why I said services. I wouldn't call getty, a service myself and you ignore baby sitting not being a central feature. You could argue a supervise service perhaps, but it's not a central feature.
you seem to want an init that does nothing at all -- and since shell is "like teh coolest thing eva .. eva", i suggest writing one in bash! it's not hard, and like i said in the past, i wrote one for LXC based systems that was ~20-30 lines, FULLY replacing sysvinit (well, i used that until systemd started to work nicely ;-)
It was originally DESIGNED to do as little as necessary and that is good design as it must run on every system and maximises UNIX usefullness to all.
On single web server this may be desired and a user installs a small package to do so that has features systemd hasn't and shouldn't have.
*yawn*
In most cases it isn't true and if you have redundant services as most do or a secure service, you don't want the service restarted as it may have been exploited, the restart may even enable the exploit, so another server will take over instead.
# systemctl stop <exploited>.service [and optionally] # systemctl disable <exploited>.service
... problem solved?
Too late, point is unnecessary feature bloat that results in bugs on more systems than need be.
Right, you've got me to waste more time than I wished, so no more.
nah friend, you did this to yourself -- no one made you do anything.
Trueish More true as arguing with these simple points shows there is no hope for rational discussion here but many will understand. -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
On Mon, Sep 03, 2012 at 11:46:14AM +0100, Kevin Chadwick wrote:
On Sat, Sep 1, 2012 at 8:46 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
On Aug 31, 2012 7:47 PM, "Kevin Chadwick" <ma1l1ists@yahoo.co.uk> wrote:
> I will give one example. Lennart says come on who connects to sshd
more
> than once a month. I can't believe he's never seen a sshd log with > constant pass attempts even though passwords are disabled.
You are misunderstanding the sshd example.
How? Systemds method would seem more problematic and wasteful to me if you get connections to it a lot.
The example explicitly only deals with the case where you do not get a lot of connections. E.g. in a private network.
"And even SSH: as long as nobody wants to contact your machine there is no need to run it, as long as it is then started on the first connection. (And admit it, on most machines where sshd might be listening somebody connects to it only every other month or so.)"
Your just making stuff up now to cover his back, which questions many of your many baseless responses simply stating I have shown I don't understand systemd, end of discussion.
It is far less likely that ssh is used behind a firewall and there is no mention of this, it is a fact that ssh is primarily used to cross the internet where it will be connected to frequently on any connection as long as it is set to the recommended default port.
i highly doubt you, Lennart, or anyone else for that matter has any real numbers to support anything being said, so please, spare me.
That would be obvious to anyone with any experience. Show me data that says sshd is used more often behind firewalls. Of course it isn't. What data that there are far more remote hosting than local hosting, of course there is, you shouldn't need data to accept this point. Just check your logs. I'd hope that if you run a daemon, you expect someone to connect to it.
I recently worked for a large international compay who provided security appliances to filter web requests,block spam, filter virus', archive email & more but these appaliances use ssh clustering where by your company purchases 4 spam & virus filter from my old employer all 4 of these appliances are linked via ssh so you only need to make changes to 1 of the 4 linked units & these changes are replicated VIA SSH & for those wishing to can connect these appliances to my employers central server farm in US & one can login to a web based admin console & make changes there which again is replicated via ssh. To add to that when a customer reqiures support this is provided via ssh. my ex-employer are market leaders in these appliance and literally have thousands scaretterd accross the globe which i think should prove that ssh is very much in use publicly & behind firewalls!
now, IME, both privately and in the numerous IT-based companies i've both worked and/or consulted with ... there are indeed usually MANY servers that happily run sshd all day long, and do not receive connections unless there is a problem.
Are these public facing on the default port as is most cases because in that case you must be looking at auth successes and not failures. Just look up why it is best to use public key and disable passwords. IT-based companies, please do they still suggest ftp for web upload by default.
regardless, Lennart's only point was "sshd should only start when someone tries to connect" ... let's not beat around the bush here, mmk?
... and a connection attempt is very different from a connection. if you really want to block the former, then you use something like fwknopd to make the sshd port invisible to everyone except the authorized. i use this on all my servers -- it's fantastic.
Funny how systemd advocates never seem to get the points. I don't want to block anything, that's what sshd does anyway without adding extra less audited crypto. You realise a server running openssl is more vulnerable to exploits than one without, right?
Are you going to miss the point and bring up web code now.
Home connections even get many ssh connection attempts
If you have a pubic IP you'd be better off using the regular service and not the xinet-style one.
The point is that much of his spec like bringing linux together and assumptions are wrong and significant sacrifices for speed bring tiny speed increases.
... tell me, have you actually ran systemd yet? hmm ...
Only on Fedora which takes longer to boot than my arch but that's irrelevant. I think the potential of speed increase has quite clearly been determined to be in the < 3 seconds range ignoring the stupid argument of what if something pauses.
Here's another assumption.
"A central part of a system that starts up and maintains services should be process babysitting: it should watch services. Restart them if they shut down."
Wrong, few want this feature and respawn and especially baby sitting is not a central feature of 'services' for an init system.
ehm, of the whopping 3 or so things sysvinit actually DID for you, wasn't respawn one of them?
That's why I said services. I wouldn't call getty, a service myself and you ignore baby sitting not being a central feature. You could argue a supervise service perhaps, but it's not a central feature.
you seem to want an init that does nothing at all -- and since shell is "like teh coolest thing eva .. eva", i suggest writing one in bash! it's not hard, and like i said in the past, i wrote one for LXC based systems that was ~20-30 lines, FULLY replacing sysvinit (well, i used that until systemd started to work nicely ;-)
It was originally DESIGNED to do as little as necessary and that is good design as it must run on every system and maximises UNIX usefullness to all.
On single web server this may be desired and a user installs a small package to do so that has features systemd hasn't and shouldn't have.
*yawn*
In most cases it isn't true and if you have redundant services as most do or a secure service, you don't want the service restarted as it may have been exploited, the restart may even enable the exploit, so another server will take over instead.
# systemctl stop <exploited>.service [and optionally] # systemctl disable <exploited>.service
... problem solved?
Too late, point is unnecessary feature bloat that results in bugs on more systems than need be.
Right, you've got me to waste more time than I wished, so no more.
nah friend, you did this to yourself -- no one made you do anything.
Trueish
More true as arguing with these simple points shows there is no hope for rational discussion here but many will understand.
-- _______________________________________________________________________
'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface'
(Doug McIlroy) _______________________________________________________________________
i highly doubt you, Lennart, or anyone else for that matter has any real numbers to support anything being said, so please, spare me.
That would be obvious to anyone with any experience. Show me data that says sshd is used more often behind firewalls. Of course it isn't. What data that there are far more remote hosting than local hosting, of course there is, you shouldn't need data to accept this point. Just check your logs. I'd hope that if you run a daemon, you expect someone to connect to it.
I recently worked for a large international compay who provided security appliances to filter web requests,block spam, filter virus', archive email & more but these appaliances use ssh clustering where by your company purchases 4 spam & virus filter from my old employer all 4 of these appliances are linked via ssh so you only need to make changes to 1 of the 4 linked units & these changes are replicated VIA SSH & for those wishing to can connect these appliances to my employers central server farm in US & one can login to a web based admin console & make changes there which again is replicated via ssh. To add to that when a customer reqiures support this is provided via ssh. my ex-employer are market leaders in these appliance and literally have thousands scaretterd accross the globe which i think should prove that ssh is very much in use publicly & behind firewalls!
It's also used for temporary remote desktop access to fix windows boxes enabled when a client loads up similar to log me in. Aside from ssh is brill, is your point that there may be many connections behind firewalls too with tunneling and such? I use ssh behind firewalls too, but in that case it is connected to many times a day by all users but it is definately a fact that ssh is mainly used for its primary purpose of crossing the internet safely, mainly to public facing remote servers. -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
On Fri, 2012-08-31 at 17:30 +0100, Kevin Chadwick wrote:
Be honest Tom, do you think it is less or more risky timewise for him to switch, right now?
That's a good question. At the moment everything I really need, does work as it should work. If I switch, nothing can become better, but it could be as good as it is now. OTOH are there risks, that something I need won't work anymore? Is systemd ready yet? Please no flame war. I don't use "testing" repositories. I contribute to Linux by testing some software, but I'm not a guinea pig for everything. Startup does work today, will it work after switching to systemd? Is it a safe bet? Regards, Ralf
On Aug 31, 2012 6:59 PM, "Ralf Mardorf" <ralf.mardorf@alice-dsl.net> wrote:
On Fri, 2012-08-31 at 17:30 +0100, Kevin Chadwick wrote:
Be honest Tom, do you think it is less or more risky timewise for him to switch, right now?
That's a good question. At the moment everything I really need, does work as it should work. If I switch, nothing can become better, but it could be as good as it is now. OTOH are there risks, that something I need won't work anymore? Is systemd ready yet?
Please no flame war. I don't use "testing" repositories. I contribute to Linux by testing some software, but I'm not a guinea pig for everything. Startup does work today, will it work after switching to systemd? Is it a safe bet?
If you don't want to help with testing, and don't need/want any of the systemd features, then you might as well wait until systemd becomes the official recommendation. Tom
On Fri, 2012-08-31 at 13:51 +0200, Damjan Georgievski wrote:
And this is yet another example how initscripts are broken. I had a friend whose GDM was not coming up because it was starting too fast after dbus. As a last resort we rearranged the DAEMONS and moved gdm as the last daemon (after NM etc) and it magically started to work.
Isn't it more likely that dbus and GDM are broken and it should be started last anyway, there's no magic.
I use GDM too, but it's not in the DAEMONS list.
[root@archlinux spinymouse]# grep DAEMONS /etc/rc.conf # DAEMONS DAEMONS=(69switch_xorg.conf hwclock syslog-ng !network !netfs crond acpid dbus networkmanager rtirq) [root@archlinux spinymouse]# pacman -Qi gdm Name : gdm Version : 3.4.1-3
*?*
You probably use the inittab method
https://wiki.archlinux.org/index.php/Display_Manager#inittab_method
Will this be an issue for him if he switches to full systemd as it has removed inittab (the one piece of init that all Linux distros had in common). -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
On Aug 31, 2012 6:32 PM, "Kevin Chadwick" <ma1l1ists@yahoo.co.uk> wrote:
On Fri, 2012-08-31 at 13:51 +0200, Damjan Georgievski wrote:
And this is yet another example how initscripts are broken. I had a friend whose GDM was not coming up because it was starting too fast after dbus. As a last resort we rearranged the DAEMONS and moved gdm as the last daemon (after NM etc) and it magically started to work.
Isn't it more likely that dbus and GDM are broken and it should be started last anyway, there's no magic.
Sounds like a dbus bug. That said, with systemd's socket activation, this bug (if it is a bug,i never heard of it before), and many like it, would no longer be a problem.
You probably use the inittab method
[...]
Will this be an issue for him if he switches to full systemd as it has removed inittab
Yes, inittab is ignored. It would be trivial to add support for it via a generator, but I don't know of any reason to. We never really used inittab in Arch. systemd's unit files are essentially a generalisation of inittab, so mimicking it is straight forward. Cheers, Tom
On Fri, Aug 31, 2012 at 06:58:02PM +0200, Tom Gundersen wrote:
On Aug 31, 2012 6:32 PM, "Kevin Chadwick" <ma1l1ists@yahoo.co.uk> wrote:
Will this be an issue for him if he switches to full systemd as it has removed inittab
Yes, inittab is ignored. It would be trivial to add support for it via a generator, but I don't know of any reason to. We never really used inittab in Arch.
Just pointing out that I have been using the inittab method since 3 years. It is also mentioned in the arch wiki, and I am sure many people use/used the inittab way.
People are grumbling about this compatibility layer, and I might change/remove it at some point. The reason I still have not ripped it out is that I like the fact that your system will "just work" as before if you add init=/bin/systemd to the kernel command line. Without the compatibility layer you'd have to also enable the relevant services (I guess that's not too much to ask though...).
I think it's asking more than commenting out the DAEMONS line?
I assumed they were used a little, if they are unused why are they required, dependencies?
Not entirely sure what you are asking. systemd-tools used to be a dependency of initscripts (it is used all over the place), now systemd-tools was merged into systemd, so systemd is a dependency of initscripts. Does that answer your question?
Thanks yeah, rc.sysinit explains the rest -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
On Aug 31, 2012 6:31 PM, "Kevin Chadwick" <ma1l1ists@yahoo.co.uk> wrote:
People are grumbling about this compatibility layer, and I might change/remove it at some point. The reason I still have not ripped it out is that I like the fact that your system will "just work" as before if you add init=/bin/systemd to the kernel command line. Without the compatibility layer you'd have to also enable the relevant services (I guess that's not too much to ask though...).
I think it's asking more than commenting out the DAEMONS line?
I'm not following, what's the question? Tom
People are grumbling about this compatibility layer, and I might change/remove it at some point. The reason I still have not ripped it out is that I like the fact that your system will "just work" as before if you add init=/bin/systemd to the kernel command line. Without the compatibility layer you'd have to also enable the relevant services (I guess that's not too much to ask though...).
I think it's asking more than commenting out the DAEMONS line?
I'm not following, what's the question?
Isn't getting rid of the compat layer going to be more work for some (not too much to ask) than those who are grumbling simply commenting out the DAEMONS line? -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
On Fri, Aug 31, 2012 at 6:41 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
People are grumbling about this compatibility layer, and I might change/remove it at some point. The reason I still have not ripped it out is that I like the fact that your system will "just work" as before if you add init=/bin/systemd to the kernel command line. Without the compatibility layer you'd have to also enable the relevant services (I guess that's not too much to ask though...).
I think it's asking more than commenting out the DAEMONS line?
I'm not following, what's the question?
Isn't getting rid of the compat layer going to be more work for some (not too much to ask) than those who are grumbling simply commenting out the DAEMONS line?
You know it is not as bad as I thought - I converted two laptops today to full systemd. Both run well after the conversion but I did it in two stages. Here are my notes: Once systemd-sysvinit is installed then initscripts and sysvinit have to be removed first and during the process rc.conf became a pacsave file so the DAEMONS line is no longer at that point after conversion. I hope these notes are helpful. The complete process took 15 minutes in each case! Working from arch systemd wiki Convert rc.conf to systemd compatible form as recommended apart from DAEMON array. Install systemd systemd-arch-units using pacman. Add init=/bin/systemd to end of kernel line in /boot/grub/menu.lst Reboot - initially only console login as it hangs at graphical.target At console hang after boot, hit return to get a login prompt then: Log in as root and do # systemctl enable graphical.target # systemctl enable kdm.service Reboot (by doing systemctl reboot) and get graphical login as normal. Check that all previous daemons from rc.conf now started and if not enable them 1) iptables appears stopped After a question on arch forum it seems that "active(exited)" is the normal status as it is a one-shot service and does not run as a daemon once the rules are loaded and dealt with by the kernel. 2) Seems alsa is legacy via rc.conf - it is running and sound is fine. In second laptop alsa was taken out of the daemon array anyway so not needed 3) cpupower frequency-info shows normal output. 4) For the journal do mkdir /var/log/journal/ and also limit the journalsize to 50M - In /etc/systemd/journald.conf add a line: SystemMaxUse=50M 5) Then needed pacman -R sysvinit initscripts which did a pacsave for /etc/rc.conf and /etc/inittab then pacman -S systemd-sysvcompat The new systemd had already installed when pacman -Syu just before this - 6) Now need to reboot and check daemon load against rc.conf.pacsave DAEMONS=(!hwclock syslog-ng iptables netfs crond sshd cupsd dbus !rpcbind postfix dovecot networkmanager alsa cpupower bluetooth named chrony) Needed: systemctl enable NetworkManager.service systemctl enable cronie.service systemctl enable sshd.service systemctl enable postfix.service systemctl enable dovecot.service systemctl enable named.service systemctl enable chrony.service systemctl enable syslog-ng.service also need: systemctl status iptables.service systemctl enable acpid.service systemctl enable cups.service Now have both syslog-ng in /var/log/messages.log and systemd journal via journalctl Conversion complete. Did the OP do something similar or have different steps? -- mike c
On Aug 31, 2012 7:47 PM, "Kevin Chadwick" <ma1l1ists@yahoo.co.uk> wrote:
Isn't getting rid of the compat layer going to be more work for some (not too much to ask) than those who are grumbling simply commenting out the DAEMONS line?
Ah, got it. There is slightly more to it than that. The way it is done now causes some confusion in a few cases (which might out-weigh the benefit). Hopefully we'll find a good solution. Tom
participants (12)
-
Allan McRae
-
baker.stephen.e＠gmail.com
-
C Anthony Risinger
-
Damjan Georgievski
-
gt
-
Kevin Chadwick
-
Mathieu R.
-
Matthew Monaco
-
mike cloaked
-
Ralf Mardorf
-
Tom Gundersen
-
Tom Rand