Re: [DNG] What can I do after netman?
I already guesed it. I added the comment in the same line because i was testing a netman.postrm file in order to remove the line added by netman in /etc/network/interfaces when the package is uninstalled. But perhaps it is not necessary. After that, i forgot to remove the comment. Thanks. Aitor. On 24/09/15 07:45, Edward Bartolo wrote: > Hi Aitor, > > fsmithred found that /etc/network/interfaces should not contain > partially commented lines. Please make sure comments are whole lines. > > Edward > > On 23/09/2015, tilt! wrote: >> > My bad, thanks for explaining - perfectly fine of course. >> > >> > Best regards, >> > T. >> > >> > Am 23.09.2015 um 20:57 schrieb aitor_czr: >>> >> Hi Tilt, >>> >> >>> >> I was referring to a branch into the netman project in Git, including >>> >> three branches: >>> >> >>> >> 1.- Upstream branch >>> >> 2.- Debian branch >>> >> 3.- Pristine-tar branch >>> >> >>> >> Being a branch in Git, the name is not confusing. See here: >>> >> >>> >> https://gitlab.com/aitor_cz/linux-libre/tree/gbp-master >>> >> >>> >> Aitor. >>> >> >>> >> On 07/04/21 23:21, aitor_czr wrote: >>> Good idea :-) >>> >>> On 22/09/15 11:20, tilt! wrote: > On 04/07/2021 10:54 PM, aitor_czr wrote: >> > gpg-netman (git-buildpackage) > > People will think it's related to "gpg", which it isn't. > > I would like to suggest the name "netman-package" for that project. > > Greetings, > T. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What can I do after netman?
I didn't express myself well. Aitor. On 23/09/2015, tilt! wrote: >> > My bad, thanks for explaining - perfectly fine of course. >> > >> > Best regards, >> > T. >> > >> > Am 23.09.2015 um 20:57 schrieb aitor_czr: >>> >> Hi Tilt, >>> >> >>> >> I was referring to a branch into the netman project in Git, including >>> >> three branches: >>> >> >>> >> 1.- Upstream branch >>> >> 2.- Debian branch >>> >> 3.- Pristine-tar branch >>> >> >>> >> Being a branch in Git, the name is not confusing. See here: >>> >> >>> >> https://gitlab.com/aitor_cz/linux-libre/tree/gbp-master >>> >> >>> >> Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems
> On September 23, 2015 at 5:44 PM Laurent Bercot wrote: > > >> if you can confirm the plan of releasing s6-rc within september > > I confirm it. > > And, lo and behold, I'm on schedule for once. > s6-rc-0.0.1.0 is out. Expubident! Peter Olson ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What can I do after netman?
I pushed to git.devuan.org all the suggested improvements: https://git.devuan.org/aitor_czr/netman/branches Thanks. Aitor. On 24/09/15 07:45, Edward Bartolo wrote: > Hi Aitor, > > fsmithred found that /etc/network/interfaces should not contain > partially commented lines. Please make sure comments are whole lines. > > Edward ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What can I do after netman?
Hi again, I uploaded the updated packages of 'netman' to: deb http://packages.gnuinos.org/devuan/ jessie main deb-src http://packages.gnuinos.org/devuan/ jessie main If you want to test them, add the above repository to your sources.list and import the public key installing: # apt-get install gnuinos-keyring Then run: # apt-get install netman-gui netman-backend Netman-gui depends on netman-backend. Aitor. El 24/09/15 a las 07:45, Edward Bartolo escribió: Hi Aitor, fsmithred found that /etc/network/interfaces should not contain partially commented lines. Please make sure comments are whole lines. Edward On 23/09/2015, tilt! wrote: >My bad, thanks for explaining - perfectly fine of course. > >Best regards, >T. > >Am 23.09.2015 um 20:57 schrieb aitor_czr: >>Hi Tilt, >> >>I was referring to a branch into the netman project in Git, including >>three branches: >> >>1.- Upstream branch >>2.- Debian branch >>3.- Pristine-tar branch >> >>Being a branch in Git, the name is not confusing. See here: >> >>https://gitlab.com/aitor_cz/linux-libre/tree/gbp-master >> >>Aitor. >> >>On 07/04/21 23:21, aitor_czr wrote: >>>Good idea:-) >>> >>>On 22/09/15 11:20, tilt! wrote: On 04/07/2021 10:54 PM, aitor_czr wrote: >gpg-netman (git-buildpackage) People will think it's related to "gpg", which it isn't. I would like to suggest the name "netman-package" for that project. Greetings, T. > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What can I do after netman?
I forgot one issue, the most important: iface wlan0 inet dhcp replicates!
I will add in netman-backend.postinst something like this:
|
FILE=/etc/network/interfaces
|if grep "^|iface wlan0 inet dhcp|" ${FILE}
then
echo "|iface wlan0 inet dhcp| allready exits in /etc/network/interfaces, doing
nothing..."
else
|
echo "iface wlan0 inet dhcp" >> /etc/network/interfaces|
fi
Aitor.
El 24/09/15 a las 13:02, aitor_czr escribió:
Hi again,
I uploaded the updated packages of 'netman' to:
deb http://packages.gnuinos.org/devuan/ jessie main
deb-src http://packages.gnuinos.org/devuan/ jessie main
If you want to test them, add the above repository to your
sources.list and import the public key installing:
# apt-get install gnuinos-keyring
Then run:
# apt-get install netman-gui netman-backend
Netman-gui depends on netman-backend.
Aitor.
El 24/09/15 a las 07:45, Edward Bartolo escribió:
Hi Aitor,
fsmithred found that /etc/network/interfaces should not contain
partially commented lines. Please make sure comments are whole lines.
Edward
On 23/09/2015, tilt! wrote:
>My bad, thanks for explaining - perfectly fine of course.
>
>Best regards,
>T.
>
>Am 23.09.2015 um 20:57 schrieb aitor_czr:
>>Hi Tilt,
>>
>>I was referring to a branch into the netman project in Git, including
>>three branches:
>>
>>1.- Upstream branch
>>2.- Debian branch
>>3.- Pristine-tar branch
>>
>>Being a branch in Git, the name is not confusing. See here:
>>
>>https://gitlab.com/aitor_cz/linux-libre/tree/gbp-master
>>
>>Aitor.
>>
>>On 07/04/21 23:21, aitor_czr wrote:
>>>Good idea:-)
>>>
>>>On 22/09/15 11:20, tilt! wrote:
On 04/07/2021 10:54 PM, aitor_czr wrote:
>gpg-netman (git-buildpackage)
People will think it's related to "gpg", which it isn't.
I would like to suggest the name "netman-package" for that project.
Greetings,
T.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems
Laurent Bercot writes: [...] > It manages dependencies between services, no matter whether they are > oneshots or longruns; it can intertwine oneshot starts and longrun > starts, or oneshot stops and longrun stops. When changing the machine > state, it always ensures the consistency of the dependency graph. I'd still very much like to see an actual example which really needs these depenencies which isn't either bogus or a workaround for a bug in the software being managed. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems
On 24/09/2015 15:31, Rainer Weikusat wrote: I'd still very much like to see an actual example which really needs these depenencies which isn't either bogus or a workaround for a bug in the software being managed. Your network must be up before you do any network connections. Your DNS cache must be up before any other service resolves names. Your filesystems must be mounted before you write to them. Want more? -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems
Laurent Bercot writes: > On 24/09/2015 15:31, Rainer Weikusat wrote: >> I'd still very much like to see an actual example which really needs >> these depenencies which isn't either bogus or a workaround for a bug in >> the software being managed. > > Your network must be up before you do any network connections. Absolutely not. By the time some process wants to make a TCP connection (example), there must be a way to transport/ route IP datagrams with a given source address to a certain destination (address), otherwise, establishing the connection will fail. This depends on the configuration of the originating host and that of (typically) numerous other computers 'on the internet' and the configuration of each involved computer including the originating host can change at any time. Hence 'failure' is part of the normal mode of operation and proccesses trying to use TCP need to deal with that. Possibly causes of 'failure' include some local admin enabling, disabling or reconfiguring interfaces at run time. > Your DNS cache must be up before any other service resolves names. Same here: DNS must be available to resolve names via DNS, otherwise, this won't work. But starting a recursive resolver before any daemon which could want to resolve names does not guarantee this. > Your filesystems must be mounted before you write to them. That's slightly different because it's obviously not possible to start a program stored in a file (which needs various other files to start) before accessing any of these files is possible (it's still subject to changes at runtime, though). But it's not necessary to declare a dependency on "the filesystem" in a dozen different files and then run some program in order to work out that "The filesystem namespace must be constructed prior to using it!" (please note that I'm intentionally ignoring NFS and such things --- network filesystems are a convenience perversion and he who uses them deserves that his blood will be on his own hands). ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Fail to install devuan-jessie-netboot-amd64-alpha2 on metal
Hi, I'll just append to this conversation as I installed the netboot successfully on my desktop pc, but I had a minor "issue". The installer went straight without asking unnecessary questions up to the point it gave me the choice of where to install the system. At that point choosing manual partitioning led me to a red screen whining about no location defined for the root filesystem. No way to go back to the previous menu nor to go past the step (obviously). Upon reboot I chose use the largest contigue space option and everithing went fine: now I have Devuan up and running on my machine! It would be nice to have this step working, though, it just happened to me on this occasion to have an extra unallocated space on my ssd I don't know if it is an issue of my particular installation or if you are aware of this "bug" Anyway I want to say thank you for the amazing work you are doing to give Devuan to the people! I would like to contribute in some way, but I am not a skilled programmer. Maybe reporting this issue could be a small small contribution. Keep on the good work! Thank you once more. Antonio On Wed, Sep 9, 2015 at 12:29 PM, Didier Kryn wrote: > Le 09/09/2015 12:38, Jaromil a écrit : > >> On Wed, 09 Sep 2015, Didier Kryn wrote: >> >>> What am I doing bad? >>> >> I believe this and other reports on missing or obsoleted packages are >> all related to the current alpha-testing of amprolla under the >> circumstances nextime has explained. >> >> Nextime is looking into this: we'd rather have this bug fixed before the >> beta release, processing the todo at our best. >> >> the code for amprolla is on gitlab if anyone wants to try to set it up >> and debug it. we did acknowledge the problem already, perhaps a better >> way to follow up can be via the gitlab issues. >> >> >> https://git.devuan.org/devuan-infrastructure/amprolla >> >> >> AFAIU, nextime has reconfigured Amprolla and rebuilt the repository, > and it is not a 30mn glitch since the behaviour didn't change during the > past 20 hours. Sorry, this infrastructure goes far above my head and I can > miss something :-) > > Didier > > > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems
On 24/09/2015 16:40, Rainer Weikusat wrote: Hence 'failure' is part of the normal mode of operation and proccesses trying to use TCP need to deal with that. Yeah, well, if your favorite startup mode is to start everything at the same time and say "eh, if it doesn't work, the program is supposed to handle failure" then your users will give you funny looks, and they will be right. I'm talking normal use cases here, i.e. situations where the services *will* succeed. In those situations, it is better to start everything according to the dependency graph, because then you do *not* trigger failure paths, which is nicer. This does not preclude programs from actually handling failure when it happens, but it's best if failure is the exception, not a normal mode of operation. That's slightly different because it's obviously not possible to start a program stored in a file (which needs various other files to start) before accessing any of these files is possible (it's still subject to changes at runtime, though). But it's not necessary to declare a dependency on "the filesystem" in a dozen different files and then run some program in order to work out that "The filesystem namespace must be constructed prior to using it!" And still, "the filesystem namespace must be constructed prior to using it". No matter how you call it, that's a dependency, and that's what I'm talking about. Now, you're free to start daemons logging stuff to /var/log/foo before mounting /var/log, but the reasonable people among us prefer not to do it. ;) -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems
On Thu, Sep 24, 2015 at 05:04:51PM +0200, Laurent Bercot wrote: [cut] > > >That's slightly different because it's obviously not possible to start a > >program stored in a file (which needs various other files to start) > >before accessing any of these files is possible (it's still subject to > >changes at runtime, though). But it's not necessary to declare a > >dependency on "the filesystem" in a dozen different files and then run > >some program in order to work out that "The filesystem namespace must be > >constructed prior to using it!" > > And still, "the filesystem namespace must be constructed prior to using it". > No matter how you call it, that's a dependency, and that's what I'm talking > about. Now, you're free to start daemons logging stuff to /var/log/foo > before mounting /var/log, but the reasonable people among us prefer not to > do it. ;) > Guys, I believe there is no need to fight on this :) I really appreciate the work done by Laurent on this front, even if I tend to agree with those who can't see the need for a process supervision system and for dependency-based boots. I will probably never end up using s6-rc, but I am happy that such kind of projects exist, if there are users/admins willing to use them. After all, one of the strongest criticism to systemd is that, for the sake of introducing a "proper" process supervision system, it has quickly swallowed most of the low-level user-space functionalities. It seems to me that s6-rc promises to focus only on process supervision and to do so in a proper KISS manner, which I personally see as a very nice thing. We have been told million times that the world is not either black or white. I tend to believe the opposite indeed (i.e., that there is *just* and *only* either black or white, in most of the cases), but I think it is fundamental for those on the black side to at least acknowledge the existence of those on the other side (and vice-versa), and then just agree to disagree ;) [*] My2Cents KatolaZ [*] Just to clarify that the black-vs-white does not have any particular connotaion, except for being a usual way of denoting dicotomic relationships. I could have used pink-vs-yellow, or purple-vs-green, or anything else instead :) -- [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems
Laurent Bercot writes: > On 24/09/2015 16:40, Rainer Weikusat wrote: > >> Hence 'failure' >> is part of the normal mode of operation and proccesses trying to use TCP >> need to deal with that. > > Yeah, well, if your favorite startup mode is to start everything at > the same time and say "eh, if it doesn't work, the program is supposed > to handle failure" then your users will give you funny looks, and they > will be right. If it starts working within less than five minutes, users will forget about it faster than they could complain, especially for a system which is usually supposed to be running. But that's actually a digression. > I'm talking normal use cases here, i.e. situations where the services > *will* succeed. In those situations, it is better to start everything > according to the dependency graph, because then you do *not* trigger > failure paths, which is nicer. Or you do trigger 'failure paths' which may not be nice at all. Eg, according to a Solaris depenency specification I saw at some time in the past, sending local mails on a Solaris system won't be allowed before LDAP has been started. But there's really no way to predict this because 'starting program A before program B' does not mean 'program A will be ready to serve program B by the time program wants to use its services'. [...] >> That's slightly different because it's obviously not possible to start a >> program stored in a file (which needs various other files to start) >> before accessing any of these files is possible (it's still subject to >> changes at runtime, though). But it's not necessary to declare a >> dependency on "the filesystem" in a dozen different files and then run >> some program in order to work out that "The filesystem namespace must be >> constructed prior to using it!" > > And still, "the filesystem namespace must be constructed prior to using it". > No matter how you call it, that's a dependency, and that's what I'm talking > about. Provided a program is supposed to work this out on its own, this information can be modelled as 'a dependency'. But you could equally well modify rc.local to do a mount-all-filesystem before a start-the-services NB: Judging from past experience, I regard "configure the system such that it's 'ready for applications" as userspace part of 'system boot'. After this has happened, applications (of all kinds) can be started in whichever way seems most suitable. But I'm not really planning to argue about that, I'm interested in situations where 'service dependencies' are actually useful. I'm convinced there aren't any but I'd gladly learn that I'm wrong[*] [*] In line of TOCTOU, there's a TOSTOU race here --- time of start is not time of use which means things can change in between and 'TOS' doesn't even guarantee that the intended situation ever existed. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems
On 24/09/2015 17:51, Rainer Weikusat wrote: If it starts working within less than five minutes, users will forget about it faster than they could complain, especially for a system which is usually supposed to be running. But that's actually a digression. Five minutes? And you think it's acceptable? Sorry, I don't have five minutes to waste every time a program fails. Also, this is 2015: if a program isn't responsive within 30 seconds, users will come knocking at your door raging - and they will be right. But there's really no way to predict this because 'starting program A before program B' does not mean 'program A will be ready to serve program B by the time program wants to use its services'. And that's why there is readiness notification, in order not to start program B before program A *can* actually serve. s6 is the only process supervision suite handling readiness notification right, thank you for underlining this. :) Provided a program is supposed to work this out on its own, this information can be modelled as 'a dependency'. But you could equally well modify rc.local to do a mount-all-filesystem before a start-the-services You mean, removing the mounts from your service manager? Sure, you can always do everything by hand. And if performing the mounts depends on something else, such as insmoding a kernel module, then you also need to do that something else by hand. And so on. Basically, you never need to use any tool if you're doing the tool's work yourself - you're just making it harder on yourself. /shrug about that, I'm interested in situations where 'service dependencies' are actually useful. I'm convinced there aren't any but I'd gladly learn that I'm wrong[*] If the "mount filesystems" example cannot convince you, nothing will, so I'll stop there. [*] In line of TOCTOU, there's a TOSTOU race here --- time of start is not time of use which means things can change in between and 'TOS' doesn't even guarantee that the intended situation ever existed. Yes, everything can fail, processes can die, the network can go down, yadda yadda yadda. It's still sensible to optimize the common case. -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems
On Thu, Sep 24, 2015 at 07:20:25PM +0200, Laurent Bercot wrote: > On 24/09/2015 17:51, Rainer Weikusat wrote: > >If it starts working within less than five minutes, users will forget > >about it faster than they could complain, especially for a system which > >is usually supposed to be running. But that's actually a digression. > > Five minutes? And you think it's acceptable? Sorry, I don't have five > minutes to waste every time a program fails. Also, this is 2015: if a > program isn't responsive within 30 seconds, users will come knocking at > your door raging - and they will be right. But let's be honest here: how many times does it happen that you have to reboot a production server nowadays? It is quite rare that a failing program actually needs a reboot, right? And even when it happens, 1 minute or 5 minutes boot won't change your overall uptime percentage that much. If you are at 99.999% with a 1 minute boot (which corresponds to one reboot every 2 months and a half, already ways too much for the vast majority of production servers) with an exagerated 5 minutes boot you will move to 99.995%. If your application is so critical to require 99.999%, then you should already have a fail-over strategy there, so you really don't mind how much time the failing server needs to come up again, since another one has alreasy taken its role and it will remain idle until the next failure happens. Again, at the end of the day all this worry about boot speed matters only for mobile devices. Which probably are a common use case, but have nothing to do with high availability. My2Cents KatolaZ -- [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What can I do after netman?
On 9/22/15, aitor_czr wrote: > XS-Vcs-Git: g...@git.devuan.org:edbarx/netman.git > XS-Vcs-Browser: https://git.devuan.org/edbarx/netman.git These two should point to a package repository not an upstream one. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems
Laurent Bercot writes: > On 24/09/2015 17:51, Rainer Weikusat wrote: >> If it starts working within less than five minutes, users will forget >> about it faster than they could complain, especially for a system which >> is usually supposed to be running. But that's actually a digression. > > Five minutes? And you think it's acceptable? As a matter of fact, I know this is more than acceptable and less than actually needed. [...] >> Provided a program is supposed to work this out on its own, this >> information can be modelled as 'a dependency'. But you could equally >> well modify rc.local to do a >> >> mount-all-filesystem >> >> before a >> >> start-the-services > > You mean, removing the mounts from your service manager? Sure, you > can always do everything by hand. That's a false dichotomoy and I 'meant' that simple ordering requirements of this kind don't have to be worked out by complicated programs at run time. NB: I've (also purposely) ignored both the flamebaits and the wrong assumptions about my situation and "situations" in general. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What can I do after netman?
What about these? deb http://packages.gnuinos.org/devuan/ jessie main deb-src http://packages.gnuinos.org/devuan/ jessie main Edward On 24/09/2015, Hleb Valoshka <375...@gmail.com> wrote: > On 9/22/15, aitor_czr wrote: > >> XS-Vcs-Git: g...@git.devuan.org:edbarx/netman.git >> XS-Vcs-Browser: https://git.devuan.org/edbarx/netman.git > > These two should point to a package repository not an upstream one. > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems
On Wed, 23 Sep 2015 23:44:36 +0200 Laurent Bercot wrote: > s6-rc features the shortest run-time code path of any service > manager to this day: this includes systemd, sysv-rc, and OpenRC. What's the benefit of having the shortest run-time code path of any service manager? Thanks, and keep up the good work! SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems
congrats to the on-time release Laurent! dear Katolaz and others On Thu, 24 Sep 2015, KatolaZ wrote: > On Thu, Sep 24, 2015 at 07:20:25PM +0200, Laurent Bercot wrote: > > On 24/09/2015 17:51, Rainer Weikusat wrote: > > >If it starts working within less than five minutes, users will > > >forget about it faster than they could complain, especially for a > > >system which is usually supposed to be running. But that's actually > > >a digression. > > > > Five minutes? And you think it's acceptable? Sorry, I don't have > > five minutes to waste every time a program fails. Also, this is > > 2015: if a program isn't responsive within 30 seconds, users will > > come knocking at your door raging - and they will be right. > > But let's be honest here: how many times does it happen that you have > to reboot a production server nowadays? I think you are overlooking the vastity of use-cases here and I agree with Laurent for a 5 minutes down you can have users raging at the door. for instance I can well imagine we may end up using s6-rc for http://dowse.equipment which isn't a server, but a home network appliance that filters a lot of traffic (adblocking and such), caches and tunnels DNS queries etc. Now if any of the daemons running on Dowse go down then the "Internet is broken" for any inhabitant on that LAN and that is the moment in which you get any other member of the household to knock the sysadmin's door - reaction times are below 1m in my experience. Dowse has the usecase addressed also regarding the long-shot and one-run services and the minimalism of s6-rc appeals me a lot for reasons you have also mentioned, I expect it to be well performant on Devuan running on embedded systems. ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems
On Thu, 24 Sep 2015 14:31:40 +0100 Rainer Weikusat wrote: > Laurent Bercot writes: > > [...] > > > It manages dependencies between services, no matter whether they are > > oneshots or longruns; it can intertwine oneshot starts and longrun > > starts, or oneshot stops and longrun stops. When changing the > > machine state, it always ensures the consistency of the dependency > > graph. > > I'd still very much like to see an actual example which really needs > these depenencies which isn't either bogus or a workaround for a bug > in the software being managed. I can't see why any init/processmanager would *not* allow intermixing. To me, this "do all oneshots before your first longrun" meme was created because people couldn't figure out how to intermix, not because there's some problem-domain reason it couldn't/wouldn't happen. I'm working with Void Linux (inits with runit) right now, and love runit, but being expected to put my one-shots in /etc/runit/1 or early /etc/runit/2 instead of making a service directory for the one-shot just seems bogus to me. From what I understand, s6-rc gets rid of this dichotomy, which I consider artificial and created only for expediency. SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems
On Thu, 24 Sep 2015 15:40:23 +0100 Rainer Weikusat wrote: > Laurent Bercot writes: > > On 24/09/2015 15:31, Rainer Weikusat wrote: > >> I'd still very much like to see an actual example which really > >> needs these depenencies which isn't either bogus or a workaround > >> for a bug in the software being managed. > > > > Your network must be up before you do any network connections. > > Absolutely not. By the time some process wants to make a TCP > connection (example), there must be a way to transport/ route IP > datagrams with a given source address to a certain destination We can argue all day about technical minutae, but the fact is it's very difficult to prove that there will never be a use case requiring a supervised long run to precede a one-shot. Demonstrating that nobody can come up with such a use case is not the same as proving that it can never happen in any use case. SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems
Jaromil writes: > congrats to the on-time release Laurent! > > dear Katolaz and others > > On Thu, 24 Sep 2015, KatolaZ wrote: > >> On Thu, Sep 24, 2015 at 07:20:25PM +0200, Laurent Bercot wrote: >> > On 24/09/2015 17:51, Rainer Weikusat wrote: >> > >If it starts working within less than five minutes, users will >> > >forget about it faster than they could complain, especially for a >> > >system which is usually supposed to be running. But that's actually >> > >a digression. >> > >> > Five minutes? And you think it's acceptable? Sorry, I don't have >> > five minutes to waste every time a program fails. Also, this is >> > 2015: if a program isn't responsive within 30 seconds, users will >> > come knocking at your door raging - and they will be right. >> >> But let's be honest here: how many times does it happen that you have >> to reboot a production server nowadays? > > I think you are overlooking the vastity of use-cases here and I agree > with Laurent for a 5 minutes down you can have users raging at the > door. > > for instance I can well imagine we may end up using s6-rc for > http://dowse.equipment which isn't a server, but a home network > appliance that filters a lot of traffic (adblocking and such), caches > and tunnels DNS queries etc. > > Now if any of the daemons running on Dowse go down then the "Internet is > broken" for any inhabitant on that LAN and that is the moment in which > you get any other member of the household to knock the sysadmin's door - > reaction times are below 1m in my experience. Well, but this wasn't about "daemons going down", it was about "faster availability after a system start" claimed to be achievable by starting services in a certain order, eg, (the only services which was actually named) start a recursive resolver before any application which could want to resolve DNS names, as opposed to "start everything in no defined order" and accept that there might be a (short) time window where some application already wants to use DNS but the DNS server/ resolver isn't yet ready to handle this request. This time window is going to be a lot less than "5 minutes" (presumably, it's going to be a lot less then 30s) and I had a particular deployment scenario in mind where certainly no one will even be able to get hold of "an IT support guy" within five minutes even assuming he'd be trying (instead of rebooting his iSomething a couple of times as that "helped in the past). This particular deployment scenario is not universal but neither is "family members come a knocking within less than a minute". ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems
Steve Litt writes: > On Thu, 24 Sep 2015 14:31:40 +0100 > Rainer Weikusat wrote: > >> Laurent Bercot writes: >> >> [...] >> >> > It manages dependencies between services, no matter whether they are >> > oneshots or longruns; it can intertwine oneshot starts and longrun >> > starts, or oneshot stops and longrun stops. When changing the >> > machine state, it always ensures the consistency of the dependency >> > graph. >> >> I'd still very much like to see an actual example which really needs >> these depenencies which isn't either bogus or a workaround for a bug >> in the software being managed. > > I can't see why any init/processmanager would *not* allow intermixing. I was asking about (complex) service dependencies because I haven't really encountered something like this so far, only declared dependencies because "we could declare them", eg, the LDAP/sendmail case on Solaris I mentioned or the fact that apache on the box I'm presently using 'depends' on bind and syslog. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems
On 24/09/2015 21:23, Steve Litt wrote: What's the benefit of having the shortest run-time code path of any service manager? - Speed: a short run-time code path means that less instructions are executed, so the job is done faster. The point is to do the amount of necessary work (calling the scripts, starting the services) with as little overhead as possible. - Safety: less run-time code means less places where things can go wrong. At this low level, it's not always possible to recover when something goes wrong; you want to perform as few instructions as possible in such a place. - Security: less code means less attack surface. A service manager usually runs as root, so it needs to be trusted code. By minimizing the amount of code run as root, you minimize the risk of exploitable security holes. - Maintainability/QA: it's easier to debug a piece of code / ensure it works properly when said piece of code is not all over the place. A bug in the s6-rc engine happens within 20 kB of code, which should make it easier to narrow down than a bug in systemd, or even in OpenRC. -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What can I do after netman?
On 9/24/15, Edward Bartolo wrote: > What about these? > > deb http://packages.gnuinos.org/devuan/ jessie main > deb-src http://packages.gnuinos.org/devuan/ jessie main >>> XS-Vcs-Git: g...@git.devuan.org:edbarx/netman.git >>> XS-Vcs-Browser: https://git.devuan.org/edbarx/netman.git >> >> These two should point to a package repository not an upstream one. Once again: XS-Vcs-* should point to VSC (git/hg/svn/etc) repository of debian package. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems
Rainer Weikusat wrote: > ... or the fact that apache on the box I'm presently > using 'depends' on bind and syslog. Well in the general case*, those are not unreasonable dependencies. In the general case*, Apache needs** DNS resolution during startup, and it rather makes sense** if it's able to log stuff while it's starting up. * And all software builds/packaging is a compromise. The package needs to support the general case, and a wide variety of not quite so general use cases. If your use case doesn't have any dependency between Apache and DNS then you are free to remove that - I know it's not exactly hard to do with Sysinit. ** Again, need is a relative term. In my experience, Apache will start "just fine" without DNS (but it does depend a little on your config), but not having DNS may mean it can't determine some values which are good for it to have. You can remove that dependency if it's not applicable to you - but for some it's "important" and it makes sense for the default to work for "most people". It doesn't absolutely need to use syslog, and it doesn't absolutely need to log stuff during startup - but in the general case it's going to cause less complaints if it's able to log stuff using syslog while starting up - if you're not bothered then you can easily change that too. The thing is, it really does not matter what decision you make - there will be a vocal minority for whom that is "completely wrong, how on earth could you do that". I've witnessed 'discussions' where someone building low footprint systems complain that (in that case, I think it was Debian) installed loads of stuff they didn't want by default, and that packages weren't modular enough to allow them to leave out the bits they didn't want. He just couldn't see that a) the default package list needs to be a reasonable compromise between installing stuff most people commonly need and space, and that b) he could easily change things himself if that default wasn't suitable - he just considered the Debian guys to be "wrong" for not supporting his exact use case by default. So how about a bit less complaining, and a bit more rejoicing that we have a lot more choice and flexibility than (say) Windows users ! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems
On Thu, Sep 24, 2015 at 02:31:40PM +0100, Rainer Weikusat wrote: > Laurent Bercot writes: > > [...] > > > It manages dependencies between services, no matter whether they are > > oneshots or longruns; it can intertwine oneshot starts and longrun > > starts, or oneshot stops and longrun stops. When changing the machine > > state, it always ensures the consistency of the dependency graph. > > I'd still very much like to see an actual example which really needs > these depenencies which isn't either bogus or a workaround for a bug in > the software being managed. Well, let's see: * cups should be started after avahi if you want zeroconf network printers accessible by name (note: X-Start-After or openrc "after" is suitable; declaring a dependency is not ideal.) * routers: - you don't want networking stuff up before your firewall - hostapd needs to start after the interface is configured - the dhcp daemon needs to start after the interface is configured (after hostapd is best, but after networking may be adequate) - the ssh server needs to start after the interface is configured, if you want to bind to a specific interface Alpine example: I want SSH on wlan0 (192.168.64.1) only. I need to specify "-p 192.168.64.1:22" in /etc/conf.d/dropbear; wlan0 must already be 192.168.64.1 for this to work. * to properly prioritize user-specified drivers, "modules" should run before driver autoload. * an entropy-gathering daemon should start after the device used have been initialized, and before the services that need random bytes start. * anything that uses the syslog should start after the syslog. While a failure to connect to /dev/log is recoverable, proper ordering will greatly simplify debugging. Now, regarding "as long as it's working in five minutes, the users will forget about it." I can only speak for myself and my family, but five minutes is far too long for me: I can boot to a desktop with a usable internet connection in ~20 seconds (the first 12 or so being BIOS+GRUB), and I'm annoyed if I can't start mutt immediately without any problems. For my parents, if the computer can't connect in the first two minutes, they might never find out that it actually does connect. And on a router, a minute is too long. HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems
On Thu, Sep 24, 2015 at 09:28:28PM +0200, Jaromil wrote: [cut] > > > > But let's be honest here: how many times does it happen that you have > > to reboot a production server nowadays? > > I think you are overlooking the vastity of use-cases here and I agree > with Laurent for a 5 minutes down you can have users raging at the door. > > for instance I can well imagine we may end up using s6-rc for > http://dowse.equipment which isn't a server, but a home network > appliance that filters a lot of traffic (adblocking and such), caches > and tunnels DNS queries etc. > I sincerely appreciate the work made by Laurent. Just please try to avoid falling in the same "everybody needs to boot-up in 12 seconds because high availability requires so" rhetoric championed by systemd-fanboys. That would do no good at all to s6-rc, and would not help acquiring new use bases, IMHO. My2Cents KatolaZ -- [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What can I do after netman?
Hi Hleb, Those lines are located in debian/control. So..., an APT repository pointing to itself? Here you are an example random search in git: https://github.com/andrenth/postfix-erlang/blob/master/debian/control Aitor. El 25/09/15 a las 05:02, Hleb Valoshka <375...@gmail.com> escribió: On 9/24/15, Edward Bartolo wrote: >What about these? > >debhttp://packages.gnuinos.org/devuan/ jessie main >deb-srchttp://packages.gnuinos.org/devuan/ jessie main >>>XS-Vcs-Git:g...@git.devuan.org:edbarx/netman.git >>>XS-Vcs-Browser:https://git.devuan.org/edbarx/netman.git >> >>These two should point to a package repository not an upstream one. Once again: XS-Vcs-* should point to VSC (git/hg/svn/etc) repository of debian package. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
