Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Sat, Dec 14, 2013 at 06:59:50PM -0600, William Hubbs wrote: > You make some good points. I'll answer your questions as best as I can, > but we can consider this thread closed. I will not try to put the > virtual in, but I will come back to the list soon and start another > thread. > > In a nutshell, our networking is a beast, and we should try to simplify > it some how imo. I'll write out my thoughts about that when I start the > other thread. > > > On Sat, Dec 14, 2013 at 11:24:10AM -0600, mingdao wrote: > > (1) What is "the new network stack" provided by the newnet USE flag? > > That consists of the network and staticroute scripts which are part of > OpenRC. The network script sets up interfaces and configures static > addresses only; it will allow you to run any command at any point in the > process of doing this. What some people on Gentoo do not like about it > is it is all or nothing. You can't start/stop/depend on a single > interface. > > The staticroute script is used to configure multiple static routes once > the network script has set up the static addresses. > > > (2) Why is dhcpcd referred to as a "network manager" in the same context as > > wicd, networkmanager, connman, etc? In the sense that dhcpcd is not > > sufficient > > for security protected wireless alone, as is, say, wicd; and is not a > > replacement for true "network manager" apps. DHCP client != network manager > > app > > This is a good point, so I will drop putting dhcpcd on the list. > > > (3) Is udhcpc provided by busybox not sufficient in lieu of dhcpcd for > > stage3? > > I think udhcpc is what you get in stage 3; if dhcpcd is there, I have no > idea how it is getting there. > > William Thanks for your kind reply, William. I'm a networking n00b, but felt those questions might benefit others, also. For (3) it seemed as if some people were saying dhcpcd is in stage 3 and they didn't want it dropped. I have a tendency to use busybox a lot doing a Gentoo install, starting with "ln -s /bin/busybox /bin/vi" :D Kindest regards, Bruce -- Happy Penguin Computers >') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
You make some good points. I'll answer your questions as best as I can, but we can consider this thread closed. I will not try to put the virtual in, but I will come back to the list soon and start another thread. In a nutshell, our networking is a beast, and we should try to simplify it some how imo. I'll write out my thoughts about that when I start the other thread. On Sat, Dec 14, 2013 at 11:24:10AM -0600, mingdao wrote: > (1) What is "the new network stack" provided by the newnet USE flag? That consists of the network and staticroute scripts which are part of OpenRC. The network script sets up interfaces and configures static addresses only; it will allow you to run any command at any point in the process of doing this. What some people on Gentoo do not like about it is it is all or nothing. You can't start/stop/depend on a single interface. The staticroute script is used to configure multiple static routes once the network script has set up the static addresses. > (2) Why is dhcpcd referred to as a "network manager" in the same context as > wicd, networkmanager, connman, etc? In the sense that dhcpcd is not sufficient > for security protected wireless alone, as is, say, wicd; and is not a > replacement for true "network manager" apps. DHCP client != network manager > app This is a good point, so I will drop putting dhcpcd on the list. > (3) Is udhcpc provided by busybox not sufficient in lieu of dhcpcd for > stage3? I think udhcpc is what you get in stage 3; if dhcpcd is there, I have no idea how it is getting there. William signature.asc Description: Digital signature
Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?
Markos Chandras wrote: > Please do not let Peter render another thread useless. Isn't it obvious that the discussion about forks is both related to cron *and* useful on its own? It's not really possible to view an entire thread as a single item. Life is more complicated than that, for good and bad. Finally, consider that even if what I write makes you personally uncomfortable it may still be useful for the community as a whole. You can only decide what is useless for you - and I don't care even if you think that I'm useless for Gentoo (I didn't say that you've said so, I am only saying if!) but I do care if you claim that your opinion is representative of the entire community, as you did above. That's not cool. Have a good weekend! //Peter
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Sat, 14 Dec 2013 15:57:04 -0600 William Hubbs wrote: > On Sat, Dec 14, 2013 at 08:47:01PM +, Jorge Manuel B. S. Vicetto > wrote: > > OK, I see what you mean. > > To be clear, I'm not ready to have a stage3 without netifrc. If / > > when we update catalyst so that the new stage3 is the sum of > > @system and additional packages, we can move netifrc to that list. > > Actually I'm not even sure how necessary that kind of update is. > > I didn't quite follow what the reasoning against my second proposal > was. > > Once openrc-0.12.4 is stable everywhere it is going to go stable, I > want to add virtual/network-manager to the tree. This would contain a > list of network manager providers. > > I think adding it to the tree is good, because we have other virtuals > for multiple packages that perform the same function -- > virtual/logger, virtual/mta, etc. > > Once that is done, we could easily add it to @system then I would drop > the netifrc use flag. That would take care of the situation if netifrc > was the default provider. > > Then, if you decide to add the function you are talking about to > catalyst, we could look into dropping virtual/network-manager from > @system. > > I'll attach the ebuild below so everyone sees it. > > William > IMHO this virtual shouldn't be added. It would be a pure meta package for the user. That case is not directly comparable with virtual/mta: We've got this for other packages to depend on it, at least that is my understanding. In a case like this, a handbook entry should suffice. Luis Ressel signature.asc Description: PGP signature
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Sat, Dec 14, 2013 at 08:47:01PM +, Jorge Manuel B. S. Vicetto wrote: > OK, I see what you mean. > To be clear, I'm not ready to have a stage3 without netifrc. If / when we > update catalyst so that the new stage3 is the sum of @system and > additional packages, we can move netifrc to that list. Actually I'm not even sure how necessary that kind of update is. I didn't quite follow what the reasoning against my second proposal was. Once openrc-0.12.4 is stable everywhere it is going to go stable, I want to add virtual/network-manager to the tree. This would contain a list of network manager providers. I think adding it to the tree is good, because we have other virtuals for multiple packages that perform the same function -- virtual/logger, virtual/mta, etc. Once that is done, we could easily add it to @system then I would drop the netifrc use flag. That would take care of the situation if netifrc was the default provider. Then, if you decide to add the function you are talking about to catalyst, we could look into dropping virtual/network-manager from @system. I'll attach the ebuild below so everyone sees it. William # Copyright 1999-2013 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: $ EAPI=5 DESCRIPTION="virtual for network managers" HOMEPAGE="" SRC_URI="" LICENSE="" SLOT="0" KEYWORDS="~x86" IUSE="" DEPEND="" RDEPEND=" || ( net-misc/netifrc >=sys-apps/openrc-0.12[newnet] signature.asc Description: Digital signature
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Sat, 14 Dec 2013, William Hubbs wrote: On Sat, Dec 14, 2013 at 05:56:33AM +, Jorge Manuel B. S. Vicetto wrote: On Tue, 10 Dec 2013, William Hubbs wrote: My issue with what we are currently doing is not whether we have a default network provider in the stages or not, but it is just that the netifrc use flag on OpenRC is bogus. OpenRC doesn't need netifrc for any reason. William, the "push" for the use flag was to ensure that users would keep the existing networking functionaility and more importantly their network configuration. Without it, portage would "happily" clean /etc/conf.d/net - something not desirable by most. Hi Jorge, Portage will not clean /etc/conf.d/net, and this is not related to the use flag. That is handled by the block starting at line 212 in openrc-0.12.4.ebuild. I had to modify the file so portage wouldn't remove it. Ah, that's good to know. I mentioned /etc/conf.d/net as you know I lost it on a production box when the new openrc with netifrc was initially released. It's good to know that was fixed on a different way. The push for the use flag was because people didn't think it was enough for me to put out a news item telling them that they should emerge netifrc if they wanted to continue using it once this version of OpenRC was installed. OK, I see what you mean. To be clear, I'm not ready to have a stage3 without netifrc. If / when we update catalyst so that the new stage3 is the sum of @system and additional packages, we can move netifrc to that list. William Jorge
[gentoo-dev] Last rites: kde-base/kdegraphics-strigi-analyzer, kde-base/kdesdk-misc, kde-base/kdesdk-scripts, kde-base/kdesdk-strigi-analyzer, kde-base/kstartperf, kde-base/kuiviewer, kde-base/solid
# Johannes Huber (14 Dec 2013) # Masked for removal in 30 days. Not packaged in current # stable KDE SC 4.11 and later. kde-base/kdegraphics-strigi-analyzer kde-base/kdesdk-misc kde-base/kdesdk-scripts kde-base/kdesdk-strigi-analyzer kde-base/kstartperf kde-base/kuiviewer kde-base/solid -- Johannes Huber (johu) Gentoo Linux Developer / KDE Team GPG Key ID F3CFD2BD signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Sat, Dec 14, 2013 at 05:56:33AM +, Jorge Manuel B. S. Vicetto wrote: > On Tue, 10 Dec 2013, William Hubbs wrote: > > > My issue with what we are currently doing is not whether we have a > > default network provider in the stages or not, but it is just that the > > netifrc use flag on OpenRC is bogus. OpenRC doesn't need netifrc for any > > reason. > > William, > > the "push" for the use flag was to ensure that users would keep the > existing networking functionaility and more importantly their network > configuration. Without it, portage would "happily" clean /etc/conf.d/net - > something not desirable by most. Hi Jorge, Portage will not clean /etc/conf.d/net, and this is not related to the use flag. That is handled by the block starting at line 212 in openrc-0.12.4.ebuild. I had to modify the file so portage wouldn't remove it. The push for the use flag was because people didn't think it was enough for me to put out a news item telling them that they should emerge netifrc if they wanted to continue using it once this version of OpenRC was installed. William signature.asc Description: Digital signature
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Tue, Dec 10, 2013 at 08:57:55PM -0600, William Hubbs wrote: > My issue with what we are currently doing is not whether we have a > default network provider in the stages or not, but it is just that the > netifrc use flag on OpenRC is bogus. OpenRC doesn't need netifrc for any > reason. > > I think if we are going to have a default network manager in the > stages we should do it by adding a virtual/network-manager then adding > that to @system. > > I couldn't find dhcpcd in @system, so I don't think it is in the > stages. > > Dhcpcd by default wants to be a standalone network manager, so I also > think it is reasonable that if you want to use dhcpcd per interface > along with netifrc you should have to make sure both of them (dhcpcd and > netifrc) are in @world. You would just have to run > emerge --noreplace netifrc dhcpcd. > > William This entire thread seems to have different terminology used by different posters, causing me some confusion. So perhaps a few questions: (1) What is "the new network stack" provided by the newnet USE flag? (2) Why is dhcpcd referred to as a "network manager" in the same context as wicd, networkmanager, connman, etc? In the sense that dhcpcd is not sufficient for security protected wireless alone, as is, say, wicd; and is not a replacement for true "network manager" apps. DHCP client != network manager app (3) Is udhcpc provided by busybox not sufficient in lieu of dhcpcd for stage3? Thanks for your explanation(s). Bruce -- Happy Penguin Computers >') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?
On 12/11/2013 03:03 PM, Mike Gilbert wrote: >> >> Is cronie a drop-in replacement, or do I have to do some thinking when >> replacing vixie-cron? >> > > It should be a drop-in. The only change to make would be to remove > vixie-cron and add cronie to the default runlevel. > I noticed two small differences: 1. Emails come from "(Cron Daemon)" instead of "Cron Daemon". 2. The binary is /usr/sbin/crond instead of /usr/sbin/cron. Everything else seems normal. Here are the steps to update; they're obvious, but it's easy to skip some accidentally: rc-update del vixie-cron default /etc/init.d/vixie-cron stop emerge -C vixie-cron emerge cronie rc-update add cronie default /etc/init.d/cronie start
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Sat, 7 Dec 2013 07:42:48 -0500 Rich Freeman wrote: > By all means have an @useful-utils set or some kind of profile that > auto-installs a list of packages like openssh, vim, and so on. > However, these are not required to bootstrap a system Since we do want net-misc/rsync, having net-misc/openssh for --rsh=ssh usage is probably unavoidable in a stage3. Also, scp. jer
[gentoo-dev] Re: Recommend cronie instead of vixie-cron in handbook?
On Wed, Dec 11, 2013, Pavlos Ratis wrote: > On Tue, Dec 10, 2013, Pacho Ramos wrote: > > > https://bugs.gentoo.org/show_bug.cgi?id=197625#c14 > > > > This has reminded me that maybe we should switch to cronie from > > vixie-cron as default and recommended cron provider in Handbook. Last > > time I checked, vixie-cron upstream was died while cronie forked it > > fixing some bugs :/ > > > > What do you think? Thanks for bringing it to attention: I've always been happy with vixie-cron, so never even thought of switching. It's good to know the code is being maintained, albeit in a fork. > I am all for it. I wouldn't say that vixie-cron is dead since it is still > functional, however I would rather say that it is outdated. > In my opinion, cronie, unlike the other cron variants is the most reliable. Ah that's good to know: the only hesitation on my part was that fcron appears more functional, but if someone wants that they can install it themselves, and this way we get anacron out of the box, and maintained code. > Also, many other distributions like Arch[1] and openSUSE[2] have already > switched from vixie-cron to cronie. Yeah that helps in terms of documentation, collaboration and just knowing it's not a risky move. I'm all for it, too, especially now Dale's done the guinea-pig run ;) Regards, steveL -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-dev] Re: rfc: renaming "rc" binary in OpenRC
William Hubbs posted on Fri, 13 Dec 2013 16:03:57 -0600 as excerpted: > On Fri, Dec 13, 2013 at 07:53:59PM +, Duncan wrote: >> William Hubbs posted on Fri, 13 Dec 2013 11:23:07 -0600 as excerpted: >> >>> There are reasons to run the rc binary directly; this is how you >>> should be changing runlevels. >> >> ??? >> >> init 9 (or telinit 9, yes, I have a runlevel 9, basic, just gpm as it >> happens) isn't appropriate? > > Well, I have to qualify what I said. > > There are two "runlevels" you have to worry about. > The OpenRC runlevels are named; you can switch between these using rc > directly, for example: > > rc default > rc single > rc nonetwork > > The sysvinit runlevels are the numbered ones, and these are mapped to > things to run, like 3 is mapped to /sbin/rc default. I believe runlevel > 3 is mapped to other things in inittab, so, I guess the best answer is, > it depends on what you are wanting to change. Does that make sense? Yes, it does. Thanks. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
