Re: [gentoo-dev] Maintainer needed: app-office/libreoffice, app-office/libreoffice-bin, app-office/libreoffice-l10n
El vie, 03-02-2012 a las 15:19 +0100, Andreas K. Huettel escribió: Dear all, Right now, noone is taking care of named packages and/or their bugs, after the most active dev left the herd. I've asked on the herd alias some days ago if anyone is willing to step in, however there was no positive reply (and barely a reply at all). For this reason I've assigned app-office/libreoffice app-office/libreoffice-bin app-office/libreoffice-l10n to maintainer-needed, and would like to ask anyone interested and willing to help to step in and revive the openoffice team. Cheers, Andreas [PS. If anyone wonders why I'm taking care of this, the openoffice team was about to become the office team some time ago, and I'm taking care of koffice / calligra and occasionally other kde-related office apps as kmymoney...] [PPS. However fitting, this only coincides with Chithanh's mail by accident...] Personally, I don't want to join because I have absolute no idea about its build system, upstream interaction and so for libreoffice :S, I am a simple libreoffice user As looks like nobody wants to join, maybe a blog entry (to be shown in planet.gentoo.org) could be posted and maybe some people tries to become a dev for libreoffice or, at least, proxy-maintain it :/ signature.asc Description: This is a digitally signed message part
[gentoo-dev] rfc: only the loopback interface should provide net
All,
I've been pondering for a while why All of OpenRC's network interfaces
provide net.
My understanding of the net service is that it is there to signal that
a generic network connection is active.
What I would like to do in OpenRC is change the network scripts so that
only the loopback interface provides net.
The down side of this approach will be that if a daemon uses a specific
ip address in its configuration, or if it binds to a specific address,
the user will have to set up the appropriate configuration options in
/etc/conf.d. For example, if I setup sshd to use 192.168.10.1 and eth0 has
this address, I have to put the following line in /etc/conf.d/sshd:
rc_need=net.eth0
One advantage I see of this approach is it will provide a fix for bugs like
http://bugs.gentoo.org/show_bug.cgi?id=228973 by requiring users to
configure services like this to start after the interface they use
is started.
Attached to this message you will find the patch I want to apply to
OpenRC to make this change.
Any thoughts, comments, or suggestions would be helpful.
William
From cf57aa084dfa3020c9f0ae1f3a07e2fbf2e588dc Mon Sep 17 00:00:00 2001
From: William Hubbs willi...@gentoo.org
Date: Mon, 6 Feb 2012 09:24:52 -0600
Subject: [PATCH] Only the loopback interface should provide net
---
init.d/net.lo.in |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/init.d/net.lo.in b/init.d/net.lo.in
index bf2d848..b3d2b1a 100644
--- a/init.d/net.lo.in
+++ b/init.d/net.lo.in
@@ -20,11 +20,10 @@ depend()
need localmount
after bootmisc
- provide net
keyword -jail -prefix -vserver
case ${IFACE} in
- lo|lo0);;
+ lo|lo0) provide net;;
*) after net.lo net.lo0 dbus;;
esac
--
1.7.3.4
pgpbYPO5ICH5v.pgp
Description: PGP signature
Re: [gentoo-dev] rfc: only the loopback interface should provide net
On 02/06/2012 01:04 PM, William Hubbs wrote: All, I've been pondering for a while why All of OpenRC's network interfaces provide net. My understanding of the net service is that it is there to signal that a generic network connection is active. What I would like to do in OpenRC is change the network scripts so that only the loopback interface provides net. The down side of this approach will be that if a daemon uses a specific ip address in its configuration, or if it binds to a specific address, the user will have to set up the appropriate configuration options in /etc/conf.d. For example, if I setup sshd to use 192.168.10.1 and eth0 has this address, I have to put the following line in /etc/conf.d/sshd: rc_need=net.eth0 That makes perfect sense. I suspect that the most common case is to have sshd bind to all interfaces, and if that's true then special configuration will not be needed in the most common cases. -- Thanks, Zac
Re: [gentoo-dev] Re: Dropping localepurge
On Tue, Jan 31, 2012 at 10:17:56AM -0500, Mike Frysinger wrote: On Monday 30 January 2012 19:39:03 »Q« wrote: AIUI, LINGUAS is the only variable that should affect what locale stuff gets installed. Is that right? yes -mike This should also affect man pages installation? Looking at LC_MESSAGES it doesn't look that bad. But man pages are out of control. Piotr Szymaniak. -- Stajesz sie odpowiedzialny na zawsze za to, co oswoiles. -- Antoine De Saint-Exupery, Le Petit Prince signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: only the loopback interface should provide net
On Mon, 2012-02-06 at 15:04 -0600, William Hubbs wrote: All, I've been pondering for a while why All of OpenRC's network interfaces provide net. My understanding of the net service is that it is there to signal that a generic network connection is active. What I would like to do in OpenRC is change the network scripts so that only the loopback interface provides net. The down side of this approach will be that if a daemon uses a specific ip address in its configuration, or if it binds to a specific address, the user will have to set up the appropriate configuration options in /etc/conf.d. For example, if I setup sshd to use 192.168.10.1 and eth0 has this address, I have to put the following line in /etc/conf.d/sshd: rc_need=net.eth0 One advantage I see of this approach is it will provide a fix for bugs like http://bugs.gentoo.org/show_bug.cgi?id=228973 by requiring users to configure services like this to start after the interface they use is started. Attached to this message you will find the patch I want to apply to OpenRC to make this change. Any thoughts, comments, or suggestions would be helpful. William I agree with the existence of the problem, but strongly disagree with the solution. There are three very different reasons why an openrc service may currently use net or need net: 1. Services that connect to remote machines via any available network interface. 2. Services that listen to connections from remote machines on any available network interface, and run correctly even if no non-lo interfaces are up. 3. Services that require a specific network interface, bind to a specific address, or connect to a specific machine on the local subnet. Category 1 includes things like ntp-client (in the typical use case). Category 2 includes things like sshd (in the typical use case). Category 3 includes things like netmount (in the typical use case), or your example of sshd that's bound to a specific static IP. The proposal to provide net only from loopback may help with startup issues for Category 2, but would break Category 1. (Category 3 is broken in either case unless the user adds the appropriate rc_need lines in /etc/conf.d). My counterproposal is to (a) fix init scripts for Category 2 so that instead of use net or need net, they only use net.lo or need net.lo; and (b) document (via pkg_postinst messages and comments in the default conf.d file) the requirement to manually configure rc_need for services in Category 3; and (c) continue to provide net in network scripts so that Category 1 continues to work. PS. Only 4 days ago, I deliberately changed /etc/init.d/NetworkManager in net-misc/networkmanager-0.9.2.0-r3 so that it provides net to ensure that Category 1 services work properly. It was rather an unpleasant surprise to now read a proposal to make the default openrc setup as broken as old networkmanager versions used to be :/ -Alexandre
Re: [gentoo-dev] rfc: only the loopback interface should provide net
Hi Alexander, On Mon, Feb 06, 2012 at 06:15:13PM -0500, Alexandre Rostovtsev wrote: I agree with the existence of the problem, but strongly disagree with the solution. Actually you have sort of helped me nail down the problem more. The issue is that the net service is broken. I'll try to point out how. 1. Services that connect to remote machines via any available network interface. 2. Services that listen to connections from remote machines on any available network interface, and run correctly even if no non-lo interfaces are up. 3. Services that require a specific network interface, bind to a specific address, or connect to a specific machine on the local subnet. Category 1 includes things like ntp-client (in the typical use case). Category 2 includes things like sshd (in the typical use case). Category 3 includes things like netmount (in the typical use case), or your example of sshd that's bound to a specific static IP. The proposal to provide net only from loopback may help with startup issues for Category 2, but would break Category 1. (Category 3 is broken in either case unless the user adds the appropriate rc_need lines in /etc/conf.d). Whether or not you break category one depends on how you define a remote machine. This is where I think the net service is broken. It is possible to have a lo interface active, without having any other network interfaces active. In the normal use case, your category one services will start (because they see that net is provided), and fail, because they can't make their connection over the loopback interface. My counterproposal is to (a) fix init scripts for Category 2 so that instead of use net or need net, they only use net.lo or need net.lo; and I think it would be better if I provided another service these scripts could use|need, because the loopback goes by at least one name other than lo that I know of, and that is lo0, so if I don't provide a service, all of these scripts would have to conditionally use or need at least lo or lo0 depending on which platform they are running on. For the normal use case, I submit that category one should not care about the loopback interface, since we don't make remote connections that way. That would mean that loopback would not provide net by default. William pgpyiKIq3ImX1.pgp Description: PGP signature
Re: [gentoo-dev] rfc: only the loopback interface should provide net
On Mon, 2012-02-06 at 19:41 -0600, William Hubbs wrote: My counterproposal is to (a) fix init scripts for Category 2 so that instead of use net or need net, they only use net.lo or need net.lo; and I think it would be better if I provided another service these scripts could use|need, because the loopback goes by at least one name other than lo that I know of, and that is lo0, so if I don't provide a service, all of these scripts would have to conditionally use or need at least lo or lo0 depending on which platform they are running on. Maybe a virtual service called lo, provided by net.lo and net.lo0? For the normal use case, I submit that category one should not care about the loopback interface, since we don't make remote connections that way. That would mean that loopback would not provide net by default. Yes, that certainly seems reasonable. -Alexandre
[gentoo-dev] Re: rfc: only the loopback interface should provide net
Alexandre Rostovtsev posted on Mon, 06 Feb 2012 21:33:39 -0500 as excerpted: On Mon, 2012-02-06 at 19:41 -0600, William Hubbs wrote: My counterproposal is to (a) fix init scripts for Category 2 so that instead of use net or need net, they only use net.lo or need net.lo; and I think it would be better if I provided another service these scripts could use|need, because the loopback goes by at least one name other than lo that I know of, and that is lo0, so if I don't provide a service, all of these scripts would have to conditionally use or need at least lo or lo0 depending on which platform they are running on. Maybe a virtual service called lo, provided by net.lo and net.lo0? For the normal use case, I submit that category one should not care about the loopback interface, since we don't make remote connections that way. That would mean that loopback would not provide net by default. Yes, that certainly seems reasonable. Indeed. I've long wondered why the loopback was thrown in there with all the others. It seems to me that a lo or loopback service for it, instead of net, would be more natural. Then have the individual net.* interface services and a common net service that by default includes all the net.* services EXCEPT loopback. Then have a configuration option such that individual installations can define what individual interface services compose net and how many of them must be up for net to be defined as up. Finally, make it possible to define additional virtual net services, net1, net2... each of which can be similarly locally configured as composed of several individual interface services, with each one allowed to set how many of its group of components must be up for it to be up. That would allow maximum configuration flexibility, with the ability to depend on one or a group of individual interface services, with each group allowed to require one of its set, all of its set, or something in between. Of course, one could add the loopback interface service to the definition of one of these groups if desired, but only the first one (net) would be defined by default, and it would by default include all interfaces /but/ loopback and would be provided when the first included interface came up. That would allow its definition to remain fuzzily specified so things could just depend on it by default if they needed an external network (ntpclient), or on loopback by default if they needed only a local interface to come up, even if they weren't a lot of use without an external network (privoxy, named). Where people want something up only if a specific net-service (or services, or one of several specific net-services) is up, they'll have to configure it specifically, just as they do now. There's no way around that since there's no simple way to determine that specific net-service in advance, but that would fix the problems for the first two categories at least, since there'd be a distinction between loopback and general net interface services. FWIW, my current config has net provided by loopback and several services depending on it, while ntpclient and ntpd depend on net.eth0. If the above defaults were implemented, that would have all just worked, since my setup isn't complex enough to have multiple external network interface services to worry about, and stuff like privoxy could be configured by gentoo to depend on loopback only, while ntpclient depends on net, which if not including loopback would allow it to just work as well. I wouldn't have had to manually configure net.eth0, as I did due to lack of that distinction. -- 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
Re: [gentoo-dev] rfc: only the loopback interface should provide net
Hi again Alexander, another question for you. On Mon, Feb 06, 2012 at 06:15:13PM -0500, Alexandre Rostovtsev wrote: 1. Services that connect to remote machines via any available network interface. 2. Services that listen to connections from remote machines on any available network interface, and run correctly even if no non-lo interfaces are up. 3. Services that require a specific network interface, bind to a specific address, or connect to a specific machine on the local subnet. Category 1 includes things like ntp-client (in the typical use case). Category 2 includes things like sshd (in the typical use case). Category 3 includes things like netmount (in the typical use case), or your example of sshd that's bound to a specific static IP. The proposal to provide net only from loopback may help with startup issues for Category 2, but would break Category 1. How would this break category 1? I see category 1 as being operationally similar to category 3. Here is why. My understanding of networking is that you can't have two interfaces with ip addresses in the same subnet on the same computer. Correct? If that is the case, more than likely, the service you want to connect to will be on one subnet or the other, but not both. So, again, depending on net is eroneous because your service could start at the wrong time, or try to connect through the wrong interface. What do you think? William pgpyR1mkY1woF.pgp Description: PGP signature
