[gentoo-user] Re: Debian just voted in systemd for default init system in jessie
The 20/02/14, Canek Peláez Valdés wrote: Thinking about this more, since apparently using a separate profile may just be 'overkill', how about something simpler, like, for example, using eselect... Something like: # eselect init list Available init systems: [1] OpenRC * [2] systemd [3] runit (whatever choices are supported). Or am I just being ridiculous? The eselect command is already there in Sabayon. No, yo are not; but the switching requires reemerging things because you need to set some USE flags and quit others. That's the difficult (which is not, really) part; if you set the USE flags yourself or via a profile, or an eselect module, I don't think the difference matters at all. ... but I have no idea how it is done. That's why I asked what packages would require a reinstall (got no precise answer for now). -- Nicolas Sebrecht
[gentoo-user] Re: technical review of systemd
The 23/02/14, Canek Peláez Valdés wrote: networkd (again, netctl is the command-line front-end) is not for enterprise networks; on the contrary, is for the trivial cases. For example, in a little web server I administer I have: $ cat /etc/systemd/system/network.service [Unit] Description=Static network service After=local-fs.target Before=network.target Documentation=man:ifconfig(8) Documentation=man:route(8) [Service] Type=oneshot RemainAfterExit=yes ExecStart=/bin/ifconfig enp2s12 192.168.1.2 broadcast 192.168.1.255 netmask 255.255.255.0 up ExecStart=/bin/route add default gw 192.168.1.1 enp2s12 [Install] WantedBy=multi-user.target (Yeah, I know, I should switch to ip, I'm sorry, I haven't had the time yet). I'm going to get rid of this trivial network.service unit file when 209 (or better 210) hits Gentoo. Cases like this are the use-cases for networkd. what i don't understand is if you look at how openRC does it, it only really cares about up/down events and the /etc/conf.d/net is very comprehensive, in part because it passes everything to iproute2 to handle, the only thing i can't do without an additional shell script is tc qdiscs. i don't need or want a network manager, just need something that applies confs on startup / stop of interfaces. I'm a little surprised that there isn't an iproute2 .service file reading through your example, in fact this is preferrable to me than using a network manager but using iproute2. I would rather you keep this example in, and have this shown on the wiki or somewhere as this neatly resolves my network concern. Mmmh. Maybe I wasn't clear; in your case, it seems that iproute2+OpenRC *is* your network manager. Perhaps at some point networkd will gain the ability to use iproute2 (or even absorb it), but right now is only for tiny little setups. The way systemd services handle network whatever network manager you enable is the last thing preventing me from using systemd on servers. Seting up manual advanced setups on systemd looks crappy (if even possible with the provided tools) compared to OpenRC. Notice that iproute2 is the default everywhere for long time, here. The OpenRC comprehensive configuration set for network management is actually what I would expect in systemd. ... Having a network manager doesn't necessarily means having a big monolithic thing that sets up your network. If you use some scripts+conf with iproute2 to set up your network, then *that's* your network manager. The point of networkd (if I understand correctly), is that if you *need* iproute2 (I don't have it installed in any of my machines), or highly dynamic non-trivial network configurations, then networkd will not be enough. And, by the way, someone make me notice that netctl is an Arch'ism, and that the command-line front-end for networkd is actually networkctl. Yes, it was taken from Arch in order to allow better network support for advanced configurations whitout requiring to write yet another tool. The thing is that I would expect systemd to handle the whole thing on its own (with the help of iproute2) so that services have nice grain-level dependencies. -- Nicolas Sebrecht
Gentoo+Gnome requires systemd, but Gnome itself does not? Why? - WAS: Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 2014-02-24 4:48 PM, Canek Peláez Valdés can...@gmail.com wrote: In Gentoo you need systemd, but that's a decision from the Gentoo maintainers. They do the job, they make the choices. Interesting. Now I have to spin off a new thread as to why this decision was made if it isn't forced by GNOME itself...
Re: Gentoo+Gnome requires systemd, but Gnome itself does not? Why? - WAS: Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 25/02/2014 14:40, Tanstaafl wrote: On 2014-02-24 4:48 PM, Canek Peláez Valdés can...@gmail.com wrote: In Gentoo you need systemd, but that's a decision from the Gentoo maintainers. They do the job, they make the choices. Interesting. Now I have to spin off a new thread as to why this decision was made if it isn't forced by GNOME itself... Gnome uses logind, Canek has consistently stated that for months now. logind is part of systemd (AIUI it's more bundled than a chunk of a monolothic lump) and replaces consolekit. The feature set of logind can be implemented in something else. Or, that functionality in previous Gnome versions forward-ported to 3.10 to be able to drop logind as a dep. OpenBSD would have had little choice in this as systemd doesn't run on OpenBSD - systemd uses many features unique to the Linux kernel. So they would have had to do *something* about logind. Whatever they did, it would have been a non-trivial amount of work. I suspect the Gentoo Gnome maintainers were not prepared to, or don't have the manpower, to do the same on Gentoo so took the easier route of depending on systemd. -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] vixie cron: PAM ERROR
On a newly installed system, I'm getting error messages from vixie cron about PAM authentication errors: Feb 25 09:52:01 alpha crond[23085]: (root) PAM ERROR (Authentication failure) Feb 25 09:52:01 alpha crond[23085]: (root) FAILED to authorize user with PAM (Authentication failure) Feb 25 09:53:01 alpha cron[23118]: (root) CMD (echo cron ran at $(date) /tmp/cron.out) Feb 25 09:53:01 alpha crond[23122]: (root) PAM ERROR (Authentication failure) Feb 25 09:53:01 alpha crond[23122]: (root) FAILED to authorize user with PAM (Authentication failure) Feb 25 09:54:01 alpha cron[23153]: (root) CMD (echo cron ran at $(date) /tmp/cron.out) Feb 25 09:54:01 alpha crond[23157]: (root) PAM ERROR (Authentication failure) Feb 25 09:54:01 alpha crond[23157]: (root) FAILED to authorize user with PAM (Authentication failure) Feb 25 09:55:01 alpha cron[23160]: (root) CMD (echo cron ran at $(date) /tmp/cron.out) Feb 25 09:55:01 alpha crond[23164]: (root) PAM ERROR (Authentication failure) Feb 25 09:55:01 alpha crond[23164]: (root) FAILED to authorize user with PAM (Authentication failure) AFAICT, it runs the scheduled command except for the very first time. I get the same results with normal user's crontab entries. -- Grant Edwards grant.b.edwardsYow! Wow! Look!! A stray at meatball!! Let's interview gmail.comit!
Re: Gentoo+Gnome requires systemd, but Gnome itself does not? Why? - WAS: Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Tue, Feb 25, 2014 at 6:58 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On 25/02/2014 14:40, Tanstaafl wrote: On 2014-02-24 4:48 PM, Canek Peláez Valdés can...@gmail.com wrote: In Gentoo you need systemd, but that's a decision from the Gentoo maintainers. They do the job, they make the choices. Interesting. Now I have to spin off a new thread as to why this decision was made if it isn't forced by GNOME itself... Gnome uses logind, Canek has consistently stated that for months now. That is true; but no one have to trust me on anything. The code is out there ([1], [2]); anyone can go and check what dependencies GNOME exactly require. logind is part of systemd (AIUI it's more bundled than a chunk of a monolothic lump) and replaces consolekit. I'm not so sure about this anymore. It seems that logind actually uses many of systemd features, and therefore is really difficult to implement independently of it. For a high overview discussion of this, you can check [3], where Ryan Lortie says: Some interfaces provided by systemd are less awesome. Even at the D-Bus level, the interface for PID 1 or logind are so complicated and implementation-specific that they could never be reasonably independently implemented. These interfaces often mix multiple functionality sets into one: for the logind case, for example, only a small subset of this is ever required by a desktop environment running as a normal user. Many other calls on the same interface are only called by other operating system components. Ubuntu has been (and supposedly, still is) interested in having a non-systemd replacement; but AFAIK, they don't have it yet. For systemd = 204 the code of logind was more independent of systemd features, so they just cut it from there; after 205 (when the new slices thingies were added to deal with the future cgroups API from the kernel), this is no longer possible, so they need to actually write an API compatible replacement. This hasn't come to fruition (and because of the above quote, this doesn't look easy). Perhaps a compromise could be reached where the desktop-necessary parts of logind are isolated in their own dbus API. As with everything, however, somebody should do that job. The feature set of logind can be implemented in something else. Or, that functionality in previous Gnome versions forward-ported to 3.10 to be able to drop logind as a dep. In this case, the something else is ConsoleKit, which (AFAIK) works in the *BSD. OpenBSD would have had little choice in this as systemd doesn't run on OpenBSD - systemd uses many features unique to the Linux kernel. So they would have had to do *something* about logind. Whatever they did, it would have been a non-trivial amount of work. I don't think so; the source code I linked says (literally): if test x$enable_systemd = xyes; then [ snip ] session_tracking=systemd (with fallback to ConsoleKit) else session_tracking=ConsoleKit fi So, it could be that is actually trivial. The real problem is that most GNOME developers don't use the ConsoleKit code paths anymore, so the burden of works goes to the people that don't have systemd (*BSD). I suspect the Gentoo Gnome maintainers were not prepared to, or don't have the manpower, to do the same on Gentoo so took the easier route of depending on systemd. Most of them don't use OpenRC anymore, so they could perhaps see that the code emerges without errors, but they would not be able to actually test it. They rather decided to support what they could test, than to give the appearance of choice when no one is really supporting the CK code paths. (Also, it seems undeniable that logind works so much better than CK ever did). Regards. [1] https://git.gnome.org/browse/gdm/tree/configure.ac#n882 [2] https://git.gnome.org/browse/gnome-session/tree/configure.ac#n123 [3] http://blogs.gnome.org/desrt/2014/02/19/on-portability/ -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] technical review of systemd
On Mon, Feb 24, 2014 at 3:09 AM, thegeezer thegee...@thegeezer.net wrote: [snip] using openrc if i reboot a system that requires fsck on /mnt/data it will do an fsck. but not log anything anywhere about the result, which is why i put this as a pro. Oh, I see; I hadn't understood this. does systemd have configurable options for '/' so that it can run readonly rather than dropping to emergency in case of problems? I believe you can run systemd out-of-the-box with / being RO. That's why /run and /run/lock are tmpfs' and they are available basically from the very beginning, and the reason /etc/mtab is a link to /proc/self/mounts. You need /var and some other stuff RW, if you want permanent logs and stuff, though. [snip] can you please clarify what you mean by absorbing iproute2? I don't use iproute2, so I don't know how big or complex it is; but if it's small and simple, it could just be absorbed in the systemd repo, like hwclock was [1]. *This is only speculation from my part*. I don't know how networkd would evolve in the future; perhaps it will always remain a little tool for trivial configurations only. And even if it evolves to cover every possible configuration on Earth, they will go with a different route from iproute2. [snip] the only reason that i bring this up is because if you _don't_ use systemd then /tmp is a folder hanging off / if you _do_ use systemd it will try to mount it tmpfs not everyone will realise this which is why i listed it as a 'gotcha' -- a nuance in working with it but not a major issue. OK, thanks for the clarification. [ snip ] thanks for the clearing up No prob. Regards. [1] http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/hwclock.c -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: technical review of systemd
On Tue, Feb 25, 2014 at 5:38 AM, Nicolas Sebrecht nsebre...@piing.fr wrote: [snip] The way systemd services handle network whatever network manager you enable is the last thing preventing me from using systemd on servers. Seting up manual advanced setups on systemd looks crappy (if even possible with the provided tools) compared to OpenRC. Notice that iproute2 is the default everywhere for long time, here. The OpenRC comprehensive configuration set for network management is actually what I would expect in systemd. Perhaps they are starting small? I don't know; from what I've read, they want something small for simple cases, and if you need more you can use NetworkManager, connman, iproute2, or whatever. But then you had to configure it yourself. [snip] And, by the way, someone make me notice that netctl is an Arch'ism, and that the command-line front-end for networkd is actually networkctl. Yes, it was taken from Arch in order to allow better network support for advanced configurations whitout requiring to write yet another tool. Nothing was taken from Arch, I believe. networkctl and netctl had nothing to do with each other. The thing is that I would expect systemd to handle the whole thing on its own (with the help of iproute2) so that services have nice grain-level dependencies. If someone writes support for this and convinces the systemd maintainers that is a good idea, I think they would accept the patches. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] vixie cron: PAM ERROR
On Tue, Feb 25, 2014 at 9:29 PM, Grant Edwards grant.b.edwa...@gmail.comwrote: On a newly installed system, I'm getting error messages from vixie cron about PAM authentication errors: Feb 25 09:52:01 alpha crond[23085]: (root) PAM ERROR (Authentication failure) Feb 25 09:52:01 alpha crond[23085]: (root) FAILED to authorize user with PAM (Authentication failure) Feb 25 09:53:01 alpha cron[23118]: (root) CMD (echo cron ran at $(date) /tmp/cron.out) Feb 25 09:53:01 alpha crond[23122]: (root) PAM ERROR (Authentication failure) Feb 25 09:53:01 alpha crond[23122]: (root) FAILED to authorize user with PAM (Authentication failure) Feb 25 09:54:01 alpha cron[23153]: (root) CMD (echo cron ran at $(date) /tmp/cron.out) Feb 25 09:54:01 alpha crond[23157]: (root) PAM ERROR (Authentication failure) Feb 25 09:54:01 alpha crond[23157]: (root) FAILED to authorize user with PAM (Authentication failure) Feb 25 09:55:01 alpha cron[23160]: (root) CMD (echo cron ran at $(date) /tmp/cron.out) Feb 25 09:55:01 alpha crond[23164]: (root) PAM ERROR (Authentication failure) Feb 25 09:55:01 alpha crond[23164]: (root) FAILED to authorize user with PAM (Authentication failure) AFAICT, it runs the scheduled command except for the very first time. I get the same results with normal user's crontab entries. -- Grant Edwards grant.b.edwardsYow! Wow! Look!! A stray at meatball!! Let's interview gmail.comit! Sounds like a pam configuration error. Try this? http://www.shanison.com/2012/02/08/crontab-error-failed-to-open-pam-security-session-success/ There are a couple of other blogs too on Google search, but all of them describe 'security error'. Your's seems to be different.
[gentoo-user] Re: vixie cron: PAM ERROR
On 2014-02-25, Grant Edwards grant.b.edwa...@gmail.com wrote: On a newly installed system, I'm getting error messages from vixie cron about PAM authentication errors: Feb 25 09:52:01 alpha crond[23085]: (root) PAM ERROR (Authentication failure) Feb 25 09:52:01 alpha crond[23085]: (root) FAILED to authorize user with PAM (Authentication failure) Doh! That's not vixie-cron, that's chronie. Feb 25 09:53:01 alpha cron[23118]: (root) CMD (echo cron ran at $(date) /tmp/cron.out) That's vixie-cron, and it's perfectly happy. I initially installed chronie (since that's what's shown in the handbook). When I couldn't get it working, I removed it and emerged vixie-cron (which I've never had any trouble with). I forgot to stop chronie before I uninstalled it. -- Grant Edwards grant.b.edwardsYow! I think my career at is ruined! gmail.com
Re: [gentoo-user] Re: vixie cron: PAM ERROR
On Tue, Feb 25, 2014 at 10:52 PM, Grant Edwards grant.b.edwa...@gmail.comwrote: On 2014-02-25, Grant Edwards grant.b.edwa...@gmail.com wrote: On a newly installed system, I'm getting error messages from vixie cron about PAM authentication errors: Feb 25 09:52:01 alpha crond[23085]: (root) PAM ERROR (Authentication failure) Feb 25 09:52:01 alpha crond[23085]: (root) FAILED to authorize user with PAM (Authentication failure) Doh! That's not vixie-cron, that's chronie. Feb 25 09:53:01 alpha cron[23118]: (root) CMD (echo cron ran at $(date) /tmp/cron.out) That's vixie-cron, and it's perfectly happy. I initially installed chronie (since that's what's shown in the handbook). When I couldn't get it working, I removed it and emerged vixie-cron (which I've never had any trouble with). I forgot to stop chronie before I uninstalled it. -- Grant Edwards grant.b.edwardsYow! I think my career at is ruined! gmail.com Ah. I use vixie-cron on servers and fcron on desktop. Fcron because it considers timing according to how much time the system was on while not accounting shutdowns. So PC doesn't miss cron jobs.
[gentoo-user] Largest Thread Ever
What is the largest thread of emails ever gentoo-user@lists.gentoo.org The debian just voted.. could possibly be a winner? Or can anyone else remember back into the depths of time. Long live Gentoo that's all I can say. Intelligent, well argued (but not always agreeing) emails chains and an OS to die for. Larry is still the best cow in the pasture. -- John D Maunder
Re: [gentoo-user] Re: technical review of systemd
On Feb 25, 2014 10:40 AM, Canek Peláez Valdés can...@gmail.com wrote: On Tue, Feb 25, 2014 at 5:38 AM, Nicolas Sebrecht nsebre...@piing.fr wrote: [snip] The way systemd services handle network whatever network manager you enable is the last thing preventing me from using systemd on servers. Seting up manual advanced setups on systemd looks crappy (if even possible with the provided tools) compared to OpenRC. Notice that iproute2 is the default everywhere for long time, here. The OpenRC comprehensive configuration set for network management is actually what I would expect in systemd. Perhaps they are starting small? I don't know; from what I've read, they want something small for simple cases, and if you need more you can use NetworkManager, connman, iproute2, or whatever. But then you had to configure it yourself. [snip] And, by the way, someone make me notice that netctl is an Arch'ism, and that the command-line front-end for networkd is actually networkctl. Yes, it was taken from Arch in order to allow better network support for advanced configurations whitout requiring to write yet another tool. Nothing was taken from Arch, I believe. networkctl and netctl had nothing to do with each other. The thing is that I would expect systemd to handle the whole thing on its own (with the help of iproute2) so that services have nice grain-level dependencies. If someone writes support for this and convinces the systemd maintainers that is a good idea, I think they would accept the patches. BTW, here is an overview of networkd by its author: https://coreos.com/blog/intro-to-systemd-networkd/ Regards.
Re: [gentoo-user] Re: technical review of systemd
Am 25.02.2014 12:38, schrieb Nicolas Sebrecht: The way systemd services handle network whatever network manager you enable is the last thing preventing me from using systemd on servers. Seting up manual advanced setups on systemd looks crappy (if even possible with the provided tools) compared to OpenRC. Yes. My current itch to scratch: set up a bonding of 2 physical NICs with systemd on gentoo. I didn't google for very long but didn't find much aside from arch linux howtos using netctl etc (which I don't know and therefore trust so much) And the network.service-files I copied and modified back then (the archives of this very ml show some of them) feel really somehow weak in a way. Aside from that I feel quite good with using systemd on all of my local gentoo systems right now (and 2 productive servers at customers .. a 3rd to come). Back then I gave it a try to simply learn by doing: ... Is it complex, is it hard to learn or use, how does it work, do I understand it, do I like the concepts ... just experience it by myself and know my way if I have to use it somewhere. I still don't judge it as good or bad. It's a choice right now. Ah, yes, and suggestions welcome for that bonded interface ;-) Stefan
Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie
On Tue, Feb 25, 2014 at 4:03 AM, Nicolas Sebrecht nsebre...@piing.fr wrote: The 20/02/14, Canek Peláez Valdés wrote: Thinking about this more, since apparently using a separate profile may just be 'overkill', how about something simpler, like, for example, using eselect... Something like: # eselect init list Available init systems: [1] OpenRC * [2] systemd [3] runit (whatever choices are supported). Or am I just being ridiculous? The eselect command is already there in Sabayon. No, yo are not; but the switching requires reemerging things because you need to set some USE flags and quit others. That's the difficult (which is not, really) part; if you set the USE flags yourself or via a profile, or an eselect module, I don't think the difference matters at all. ... but I have no idea how it is done. That's why I asked what packages would require a reinstall (got no precise answer for now). Sabayon uses binary packages, isn't? Then eselect perhaps uninstalls some packages and installs others? I've no idea; I've never used Sabayon, although I'm interested in trying it. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
