Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On Mon, 17 Apr 2017 10:09:02 +0200 exha...@posteo.net wrote: > in the same way that there's not a perfect graphical desktop for all > the people, Quoted for truth! You can't *download* or *install* the perfect GUI desktop, you must construct the GUI desktop that's best for you. And that requires interchangeable parts. I sense a theme here. SteveT Steve Litt April 2017 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On Tue, Apr 18, 2017 at 03:36:09AM -0400, Steve Litt wrote: > On Mon, 17 Apr 2017 10:09:02 +0200 > exha...@posteo.net wrote: > > > in the same way that there's not a perfect graphical desktop for all > > the people, > > Quoted for truth! > > You can't *download* or *install* the perfect GUI desktop, you must > construct the GUI desktop that's best for you. And that requires > interchangeable parts. > > I sense a theme here. > The theme is quite easy to spot, and has been around for the best part of the last 50 years: small, reusable, interchangeable components, each providing a single, atomic, simple mechanism, avoiding to mess up with policies (which are for the perusal of humans, not machines...). This is what KISS is all about. We have always needed and will always need more software. But never "more standard policies" or "unique and perfect solutions" for each problem. Those are quests for fools. HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
Alessandro Selli: > On Fri, 14 Apr 2017 at 12:06:44 +0200 (CEST) > k...@aspodata.se wrote: > > Enrico Weigelt: > > ... > > > Let's just take some example: libsrvmgt with funcs like that: > > > > > > * srvmgt_daemonize() > > > --> detach from controlling terminal, etc > > > > Why do any monitor program need to know if the program has detached > > or not, the only thing it needs to know is the pid and the state, > > which would/could be provided by the *_state() functions, > > or am I wrong ? > All daemons detach from the control terminal. A daemon from a daemon ? > The monitor and the > daemon must coordinate each other about who's doing the detach to avoid > launch time failures. The program to become the daemon, how does it knows if it has a monitor or not ? And if it doesn't know, how can one demand that it should coordinate with something unknown ? And why should a program/daemon care if it has a monitor or not ? > > > * srvmgt_droppriv(...) > > > --> drop root privileges (if we are still root) > > > --> several versions, eg. with fetching the target uid/gid from env > > > > Given the pid, it isn't that hard for a monitor to find the uid/gid of > > the process, why has this have to go through the monitor ? > > I don't think here the monitor is used to extract process info (such > as user/group it's running under), rather the environment is used to > determine what user:group the daemon must be set to by the monitor. I don't follow you. If the monitor shouldn't know much about the child as stated by someone somewhere else in this thread, why should the monitor need to know user:group ? And if it should know it, why trust the monitored program when the kernel can give you the info ? > > Also, given that you can do the above without this lib opens gives the > > program the option too cheat, say, if the monitor wishes to have a > > tight control of the process. > > It depends by where is that environment set. It might be a config > file. You're supposed to trust your config files. Or, rather, the user is responsible for the config file, not the program reading it, so yes the program generally trusts the config file "since I demand it". And what is your point ? > > > * srvmgt_report_state(...) > > --> report the service state to the supervisor > > ... > > > > There could be something like *_a_would_like_to_be_monitored() and > > *_I_wish_to_regain_my_free_will(). > > The monitor is supposed to implement local security/service > continuity/resource allocation policies the daemon must not be able to > bail itself out of. It seems you have the view that a monitor has to police a program. I don't think one should have such a strict view. > > > --> states could be eg. > > > * SRVMGT_STATE_STARTUP -- still within the startup phase > > > * SRVMGT_STATE_READY_LOCAL -- ready for local clients only > > > * SRVMGT_STATE_READY_ALL -- ready for all clients > > > * SRVMGT_STATE_BUSY-- too busy to process new requests > > > * SRVMGT_STATE_SHUTDOWN-- shutting down, still finishing > > > queued requests > > > * SRVMGT_STATE_DEFERRED-- temporarily can't accept new > > > requests (eg. overload) > > > * SRVMGT_STATE_WAITING -- wait for resource (eg. printer > > > needs paper or ink) > > > * SRVMGT_STATE_OFFLINE -- completely offline (eg. due some > > > fatal error) > > > > Given the choises given, it seems that the target of the monitor is > > network servers. Couldn't the monitor find out the ready_local, > > ready_all and shutdown by itself by monitoring which ports are open ? > > The monitor is not supposed to always grant any daemon any port it > wishes. ... Why, the monitor is not a firewall. It seems you and I have different views about what a monitor is and should/shouldn't do. > > And, what if the monitor cannot trust the program it monitors ? > > Given the lib suggestion, it seems that we are trusting the program. > > Well... what if you do not trust the monitor? Then I wouldn't run it, would you ? > What do you mean by what you wrote? How do you think you can teach a > monitor if some program can be trusted? ... The monitor doesn't have to trust a specific program if it can get the the wanted info from the kernel. If I can get the info I want from the kernel, why should I ask the program ? If the kernel say something and the program something else, which one do you trust more ? > > But what if if we don't know if we can trust the walues provided by > > the program, the we have to check what the program is really doing, > > and then the lib have no value, isn't that so ? > > Could you please provide us with an example of untrusted > behaviour/program provided data that the monitor is supposed to detect > and handle accordingly? First off, we seems to have dif
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On 18/04/2017 at 10:35, k...@aspodata.se wrote: > Alessandro Selli: >> On Fri, 14 Apr 2017 at 12:06:44 +0200 (CEST) >> k...@aspodata.se wrote: >>> Enrico Weigelt: >>> ... Let's just take some example: libsrvmgt with funcs like that: * srvmgt_daemonize() --> detach from controlling terminal, etc >>> Why do any monitor program need to know if the program has detached >>> or not, the only thing it needs to know is the pid and the state, >>> which would/could be provided by the *_state() functions, >>> or am I wrong ? >> All daemons detach from the control terminal. > A daemon from a daemon ? Isn't init a daemon? Isn't inetd/xinetd a daemon? >> The monitor and the >> daemon must coordinate each other about who's doing the detach to avoid >> launch time failures. > The program to become the daemon, how does it knows if it has a monitor > or not ? In the case of init being the monitor, it can check if it's parent has PID 1. The classical approach is to configure the daemon to do the right thing, i.e. to do the detach himself when run with the --daemon switch or when the config file has a similar item configured, to let the monitor do it otherwise or if explicitly told not to daemonize (some programs have a --no-daemon or --foreground or --debug switch to override the config file settings). This is old-school Unix, classical Unix daemon have had these items (switches and config files) for many ten years... the modern approach in Linux entails IPC, dbus, sockets to have messages passed from the monitor to daemons and back. > And if it doesn't know, how can one demand that it should > coordinate with something unknown ? Config files, command line switches. > And why should a program/daemon care if > it has a monitor or not ? Why should a car driver care if the traffic light has the red or the green light turned on? Why should a sysadmin care if the OS he uses runs systemd or not? * srvmgt_droppriv(...) --> drop root privileges (if we are still root) --> several versions, eg. with fetching the target uid/gid from env >>> Given the pid, it isn't that hard for a monitor to find the uid/gid of >>> the process, why has this have to go through the monitor ? >> I don't think here the monitor is used to extract process info (such >> as user/group it's running under), rather the environment is used to >> determine what user:group the daemon must be set to by the monitor. > I don't follow you. If the monitor shouldn't know much about the child > as stated by someone somewhere else in this thread, why should the > monitor need to know user:group ? Again, as far as I understood what Enrico Weigelt wrote, the monitor does not want to know the user:group the daemons runs under, it needs to *set* them to the appropriate values when it launches the daemon to have them reflect config file settings or local policies. > And if it should know it, why trust > the monitored program when the kernel can give you the info ? Again, the relevant info is supposed to be set in config files. The user:group the daemon must run under is not up to the daemon itself, they are set in config files, either the deamon's or the monitor's. >>> Also, given that you can do the above without this lib opens gives the >>> program the option too cheat, say, if the monitor wishes to have a >>> tight control of the process. >> It depends by where is that environment set. It might be a config >> file. You're supposed to trust your config files. > Or, rather, the user is responsible for the config file, not the program > reading it, so yes the program generally trusts the config file "since I > demand it". And what is your point ? That the relevant info is set in the config files, they are not made up by the program itself and trusted by the monitor. The trust is placed into the config files. * srvmgt_report_state(...) >>> --> report the service state to the supervisor >>> ... >>> >>> There could be something like *_a_would_like_to_be_monitored() and >>> *_I_wish_to_regain_my_free_will(). >> The monitor is supposed to implement local security/service >> continuity/resource allocation policies the daemon must not be able to >> bail itself out of. > It seems you have the view that a monitor has to police a program. Many monitor also do this, some are setup mainly for this reason. Xinetd has several config items related to security or resource policing: some "flags" (like IDONLY and INTERCEPT), the "user" and "group" settings, "libwrap", "only_from", "no_access", "access_times", "redirect", "bind", "per_source", "cps" (connections per second), "max_load", "umask", "rlimit_(as|cpu|data|rss|stack)", "passenv", "deny_time". It's good they are available, that you use them or don't. > I don't think one should have such a strict view. If you don't want them, don't use them. Let other people decide otherwise, though. There is not a single use case that
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On Tue, Apr 18, 2017 at 12:21:05PM +0200, Alessandro Selli wrote: [cut] > > > And why should a program/daemon care if > > it has a monitor or not ? > > Why should a car driver care if the traffic light has the red or the > green light turned on? > Why should a sysadmin care if the OS he uses runs systemd or not? > This is a totally wrong assumption. Being a sysadmin is all about setting and implementing *policies*. And the choice between systemd or anything else is exactly a matter of policy. So yes, a sysadmin *must* care if the OS he/she uses runs systemd or anything else. HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On Tue, 18 Apr 2017 11:32:00 +0100 KatolaZ wrote: > > Why should a car driver care if the traffic light has the red or the > > green light turned on? > > Why should a sysadmin care if the OS he uses runs systemd or not? > > > > This is a totally wrong assumption. Being a sysadmin is all about > setting and implementing *policies*. And the choice between systemd or > anything else is exactly a matter of policy. So yes, a sysadmin *must* > care if the OS he/she uses runs systemd or anything else. He should care, as he has to know whether it is a unix/linux system or a systemd system, the two being rather different in their management... Cheers, Ron. -- Eat drink and be merry, for tomorrow we may diet. -- http://www.olgiati-in-paraguay.org -- ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On 18/04/2017 at 12:32, KatolaZ wrote: > On Tue, Apr 18, 2017 at 12:21:05PM +0200, Alessandro Selli wrote: > > [cut] > >>> And why should a program/daemon care if >>> it has a monitor or not ? >> Why should a car driver care if the traffic light has the red or the >> green light turned on? >> Why should a sysadmin care if the OS he uses runs systemd or not? > This is a totally wrong assumption. Being a sysadmin is all about > setting and implementing *policies*. And the choice between systemd or > anything else is exactly a matter of policy. So yes, a sysadmin *must* > care if the OS he/she uses runs systemd or anything else. Which is exactly my point. I am not advocating in favor of systemd any more than I'm advocating letting drivers ignore traffic lights. And what I don't like of Karl Aspo's idea is that it takes any instrument of policy checking and enforcing out of the monitor, which ends up not being able to monitor anything, it becomes just a shell: fire and forget. I was also been ironic on Aspo, as many times he can only counter another person's ideas asking "What if cannot be trusted?", as if this constitutes a valid argument against being able to set policies for the monitor to enforce on the daemons it runs. In this case, asking "why should a program/daemon care if it has a monitor or not ?" is moot, because that the daemon is aware or not that it was launched by a monitor and if so by what monitor, does not change anything about the monitor's functions and duties. The daemon doesn't care if it's run by a monitor? The monitor is still there, and it does care about the program. A driver does not care if the traffic light is red or green? The street police does. Alessandro ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On Tue, Apr 18, 2017 at 11:32:00AM +0100, KatolaZ wrote: > On Tue, Apr 18, 2017 at 12:21:05PM +0200, Alessandro Selli wrote: > > Why should a car driver care if the traffic light has the red or the > > green light turned on? > > Why should a sysadmin care if the OS he uses runs systemd or not? > > This is a totally wrong assumption. Being a sysadmin is all about > setting and implementing *policies*. And the choice between systemd or > anything else is exactly a matter of policy. So yes, a sysadmin *must* > care if the OS he/she uses runs systemd or anything else. I don't care whether the OS runs systemd, sysv-rc, openrc or an enslaved young boy sitting at the console and starting daemons by hand. What I do care about is whether it: * implements standard interfaces * is correct while doing so My beef with systemd is that it has egregious bugs (some due to mistakes, some due to intentional brain damage), and that working around bugs or places where it doesn't meet your particular use case is a matter of a single line of shell on sysv-rc but on systemd it's a hopeless case of digging through a giant blob of spaghetti code. A sample openrc (init script?) bug: [ ok ] Asking all remaining processes to terminate...done. Currently running processes (pstree): init-+-2*[nbd-client] `-rc---openrc---openrc-run---sendsigs---pstree [FAIL] Killing all remaining processes...failed. Stopping NBD client process: disconnect, [17892.932316] block nbd0: NBD_DISCONNECT sock, [17892.937274] block nbd0: shutting down sockets done disconnect, [17892.951774] block nbd1: NBD_DISCONNECT sock, [17892.956734] block nbd1: shutting down sockets done rmmod: ERROR: Module nbd is in use nbd-client. [warn] not deconfiguring network interfaces: network devices still mounted. ... (warning). [info] Saving the system clock. [info] Hardware Clock updated to Tue Apr 18 13:18:23 CEST 2017. [ ok ] Deactivating swap...done. [] Unmounting local filesystems...[17896.568144] block nbd0: Attempted send on invalid socket [17896.573501] blk_update_request: I/O error, dev nbd0, sector 4257856 [17896.579804] block nbd0: Attempted send on invalid socket [17896.585125] blk_update_request: I/O error, dev nbd0, sector 4258112 [17896.591402] BTRFS error (device nbd0): bdev /dev/nbd0 errs: wr 1, rd 0, flush 0, corrupt 0, gen 0 [17896.600422] block nbd0: Attempted send on invalid socket [17896.605741] blk_update_request: I/O error, dev nbd0, sector 4262496 [17896.612018] block nbd0: Attempted send on invalid socket A sysadmin who doesn't know the proper way to fix this can still trivially deal with the issue. Don't know how to make nbd-client stop _after_ network filesystems are unmounted? Just plop in a manual unmount somewhere. Here, your system is fixed, you can then learn when you got a bit of time. A sample systemd bug: A common way to backup/search/etc a filesystem that has something mounted in random subdirectories is to "mount --bind / /mnt/ref/rootfs; mount --bind /home /mnt/ref/home" and so on, so you don't risk a naive script getting into a loop. Except, systemd sometimes decides to convert that --bind into a --rbind (specifically what you wanted to avoid!); it might happen a fraction of second after the mount, several minutes or apparently never. So you can't even rely on that bug happening or not. It will also sometimes decide to _unmount_ what you just mounted (most often on a degraded raid). Now try to work around this... -- ⢀⣴⠾⠻⢶⣦⠀ Meow! ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second ⠈⠳⣄ preimage for double rot13! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On Tue, Apr 18, 2017 at 01:32:01PM +0200, Adam Borowski wrote: [cut] > > > > This is a totally wrong assumption. Being a sysadmin is all about > > setting and implementing *policies*. And the choice between systemd or > > anything else is exactly a matter of policy. So yes, a sysadmin *must* > > care if the OS he/she uses runs systemd or anything else. > > I don't care whether the OS runs systemd, sysv-rc, openrc or an enslaved > young boy sitting at the console and starting daemons by hand. What I do > care about is whether it: > * implements standard interfaces > * is correct while doing so > This is exactly my point :) A sysadmin *must* care about init because not all the enslaved young boys sitting at the root console react or complain in the same way. Some of them just limit their actions to obeying to what the sysadmin asks them to do, and let the sysadmin choose and implement the policy he/she wants. Some other are quite opinionated guys. They come with their pre-defined policies (often called "typical use cases"), which are often terribly hard to work around, and stubbornly refuse to obey if the sysadmin does not align to those "typical use cases". This is something most sysadmin cannot (and should not) tolerate... HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
Allesandro, I'm not interested in a debate (people talking past each other), I'm interested in understanding why the proposed library and it function calls are such a good idé, since I don't think it is. Wheter to run a monitor or not is a different question, which I consider is up to the local admin. Why srvmgt_daemonize(), use -f and daemon() and you'd be fine in either camp, end case. Why srvmgt_droppriv(), either accept that the process set's it itself or force it to some uid:gid, what is it more to it ? Why srvmgt_report_state(), just do a normal query to the process and you'll know if it is ready to serve you or not, if you want to know if it is up to speed, do a benchmark, if you want to test the integrity, do a regression test; what is it more to it ? (And, yes, a monitoring program can do the above for you.) I don't get the point of all this, can you explain ? Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why I don't want to have Pöttersoft on my system
Le 17/04/2017 à 16:54, Enrico Weigelt, metux IT consult a écrit : On 17.04.2017 16:37, Joachim Fahrner wrote: Am 2017-04-17 11:18, schrieb Klaus Ethgen: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 https://github.com/systemd/systemd/issues/5644 No further comment needed. Have fun reading. (Found on popular fefe blog) ROTFL Stupid question: why does systemd implement a rm command? They sold us systemd as an init sytem. Maybe they should just merge in busybox ;-) Busybox isn't a monolithic system you need to link applications against, nor does it force you to depend on it. It *can* be built as a single executable, as a conveniency for those who don't want to have dynamic libraries in their way. Busybox provides its own init, which is not systemd, and it does not force you to use it. You build your own Busybox implementing the apps you want and only them. I guess you didn't intend to introduce any confusion, but it might arise from your last sentence. Cheers. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
I've read this thread fairly thoroughly, but fail to see much of a use case... There's hypothetical stuff, what if service x needs service y. Well, what if it does. Should it demand that y be running at every moment and on the same host? DOES it demand that? This isn't a good thing to spend effort on. The trend today is towards services that require only an OS absolutely. A modern service requires e.g. a read/write file system and/or a network interface with addressing and routing. If a modern service uses something like an SQL database, it'll paper over inavailability, it'll delay, retry, reconnect. The fashionable rationale is cloudy wizbangery. But a notable side effect is that postgresql and services that use postgresql can start at the same time. I'm not saying that ALL services cope with unavailable dependencies. What I am saying is rather that spending effort on supporting this kind of dependency management has low and decreasing value. AWS and other systems that provision instances according to need push strongly on server software to cope with momentary inavailability, odd starting order, etc. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
Alessandro Selli: ... > And > what I don't like of Karl Aspo's idea is that it takes any instrument of > policy checking and enforcing out of the monitor, which ends up not > being able to monitor anything, it becomes just a shell: fire and forget. I honestly do not understand what I have written which gives you that idé. > I was also been ironic on Aspo, as many times he can only counter > another person's ideas asking "What if cannot be trusted?", > as if this constitutes a valid argument against being able to set > policies for the monitor to enforce on the daemons it runs. If I can get a value from the kernel instead of from the process, I'd take the kernel value. Why do a process have to query the kernel to get a value and then sending it to a monitor over a communication link; why don't the monitor query the kernel itself, saving one step. > In this > case, asking "why should a program/daemon care if it has a monitor or > not ?" is moot, because that the daemon is aware or not that it was > launched by a monitor and if so by what monitor, does not change > anything about the monitor's functions and duties. The daemon doesn't > care if it's run by a monitor? The monitor is still there, and it does > care about the program. It would help my understanding if you simply answered my question. > A driver does not care if the traffic light is > red or green? The street police does. This is not as a suitable metaphor as you think it is. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On Tue, Apr 18, 2017 at 03:11:51PM +0200, k...@aspodata.se wrote: [cut] > > > I was also been ironic on Aspo, as many times he can only counter > > another person's ideas asking "What if cannot be trusted?", > > as if this constitutes a valid argument against being able to set > > policies for the monitor to enforce on the daemons it runs. > > If I can get a value from the kernel instead of from the process, > I'd take the kernel value. > > Why do a process have to query the kernel to get a value and then > sending it to a monitor over a communication link; why don't the > monitor query the kernel itself, saving one step. > I genuinely don't understand why the kernel should know about the internals of running processes, or get notified if a process is "ready" to do whatever it is supposed to do, or get queried by other processes which would like to access this kind of information, or maintain such information in the first instance... A general-purpose unix-like kernel must do what it has been designed for: providing access to hardware resources (memory and devices) and schedule processes. Maybe you need another (non-unix-like and non-general-purpose) operating system? HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On Tue, Apr 18, 2017 at 02:15:38PM +0100, Arnt Gulbrandsen wrote: > I've read this thread fairly thoroughly, but fail to see much of a use > case... > > There's hypothetical stuff, what if service x needs service y. Well, what if > it does. Should it demand that y be running at every moment and on the same > host? DOES it demand that? > Unfortunately we are already paying the consequences of badly-written software implementing oddly-designed solutions to non-existing problems... HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
kato...@freaknet.org writes: I genuinely don't understand why the kernel should know about the internals of running processes, or get notified if a process is "ready" to do whatever it is supposed to do, or get queried by other processes which would like to access this kind of information, or maintain such information in the first instance... Indeed. Particularly in light of the modern fashion of running things on other hosts reachable across the network, perhaps via load balancers that complicate the availability state machine. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
kato...@freaknet.org writes: Unfortunately we are already paying the consequences of badly-written software implementing oddly-designed solutions to non-existing problems... Indeed. But what's your point? Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On 18/04/2017 at 15:11, k...@aspodata.se wrote: > Alessandro Selli: > ... >> And >> what I don't like of Karl Aspo's idea is that it takes any instrument of >> policy checking and enforcing out of the monitor, which ends up not >> being able to monitor anything, it becomes just a shell: fire and forget. > I honestly do not understand what I have written which gives you that idé. Your many lines that the monitor is not to do any monitoring. Like: "Why do any monitor program need to know if the program has detached or not, the only thing it needs to know is the pid and the state,". >> I was also been ironic on Aspo, as many times he can only counter >> another person's ideas asking "What if cannot be trusted?", >> as if this constitutes a valid argument against being able to set >> policies for the monitor to enforce on the daemons it runs. > If I can get a value from the kernel instead of from the process, > I'd take the kernel value. What value? Of course there are values that are set and managed by the kernel, not by the process, and are thus most dependable when extracted from the kernel itself. However other values are specific to the daemon and the kernel doesn't care/know anything of, like what virtual domains the webserver is handling, of how many domains the DNS server is master. Anyway, this has very little (if anything) to do with the monitor's need to be able to... monitor the processes it launches, set them to the wanted user:group and the daemons knowing whether they are to detach from the controlling terminal or not. > Why do a process have to query the kernel to get a value and then > sending it to a monitor over a communication link; why don't the > monitor query the kernel itself, saving one step. Where did Enrico Weigelt write the monitor should get it's child PID from the process itself? This subthread started from these lines: >> * srvmgt_droppriv(...) >> --> drop root privileges (if we are still root) >> --> several versions, eg. with fetching the target uid/gid from env > Given the pid, it isn't that hard for a monitor to find the uid/gid of > the process, why has this have to go through the monitor ? >> In this >> case, asking "why should a program/daemon care if it has a monitor or >> not ?" is moot, because that the daemon is aware or not that it was >> launched by a monitor and if so by what monitor, does not change >> anything about the monitor's functions and duties. The daemon doesn't >> care if it's run by a monitor? The monitor is still there, and it does >> care about the program. > It would help my understanding if you simply answered my question. An answer to a moot question is Mu! (https://en.wikipedia.org/wiki/Mu_%28negative%29) The only point of any technical interest was already answered: «All daemons detach from the control terminal. The monitor and the daemon must coordinate each other about who's doing the detach to avoid launch time failures.» And again, so long as it's configured the right way, that the daemon is aware that it is run under a monitor or not is irrelevant: it is the monitor that need to be aware of it's children processes, their status and operational parameters, because it is responsible of what they do, starting from setting the user:group they run under. Daemons should behave the same no matter under what monitor they are running under, they are not to care about this. This is one of the reasons systemd is bad. Still, the monitor does the monitoring. >> A driver does not care if the traffic light is >> red or green? The street police does. > This is not as a suitable metaphor as you think it is. It is, no matter what you think about it. Alessandro ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On Tue, Apr 18, 2017 at 02:48:54PM +0100, Arnt Gulbrandsen wrote: > kato...@freaknet.org writes: > >Unfortunately we are already paying the consequences of badly-written > >software implementing oddly-designed solutions to non-existing > >problems... > > Indeed. But what's your point? > Oh, you are right, I didn't make it explicit: my humble opinion is that the whole thread is not particularly interesting or useful in this context, since all this fuss about monitoring/supervision boils down to two alternative options: a) you *really* need *strict* monitoring/supervsion. In this case, you *don't* use a unix-like operating system, since you are always left at least with the problem of monitoring the monitor (or supervising the supervisor). But this is not a real problem, since in those environments where *strict* supervision/monitoring is *really* necessary, unix-like systems are rarely used, if ever, and the scheduler also acts as a monitor/supervisor. So if you need *real* *strict* monitoring, the whole topic is off-topic here. b) you need *loose* monitoring/supervision. In this case, you pick and choose among what is available, or write your own. In any case, you get a monitor/supervisor running as a user process on top of any general-purpose operating system, possibly a unix-like one, and your applications must still be able to deal with faults, inconsistencies, delays, and other issues. And sometimes you will still need manual intervention nonetheless. The "everything will be all right" theme is just dust in your eyes, because things are never going to be all right all the time. There is really no other reasonable alternative, IMVHO. But I am not an expert in the field (though I am quite happy about not being an expert, having seen what the "experts in the field" have been able to come up with in the last couple of years...) My2Cents KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
Katola2: > On Tue, Apr 18, 2017 at 03:11:51PM +0200, k...@aspodata.se wrote: ... > > If I can get a value from the kernel instead of from the process, > > I'd take the kernel value. > > > > Why do a process have to query the kernel to get a value and then > > sending it to a monitor over a communication link; why don't the > > monitor query the kernel itself, saving one step. > I genuinely don't understand why the kernel should know about the > internals of running processes, or get notified if a process is ... What is the problem with you guys, I did write "if". That "if" applies to thing like PID, uid, gid and such of processes, not wheter they are in some sense ready or not. Please, don't continously misinterpret me. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
Alessandro: > On 18/04/2017 at 15:11, k...@aspodata.se wrote: > > Alessandro Selli: > > ... > >> And > >> what I don't like of Karl Aspo's idea is that it takes any instrument of > >> policy checking and enforcing out of the monitor, which ends up not > >> being able to monitor anything, it becomes just a shell: fire and forget. > > I honestly do not understand what I have written which gives you that idé. > Your many lines that the monitor is not to do any monitoring. Like: > "Why do any monitor program need to know if the program has detached or > not, the only thing it needs to know is the pid and the state,". You cut out the thing after the "," which makes that a question for someone else to fill in the blanks, the things that's not obvious to me. If a process knows the pid of another process and have sufficient rights, can it not manage that process or is there anything else it needs to know, what am I missing ? Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On 18/04/2017 at 16:42, k...@aspodata.se wrote: > Alessandro: >> On 18/04/2017 at 15:11, k...@aspodata.se wrote: >>> Alessandro Selli: >>> ... And what I don't like of Karl Aspo's idea is that it takes any instrument of policy checking and enforcing out of the monitor, which ends up not being able to monitor anything, it becomes just a shell: fire and forget. >>> I honestly do not understand what I have written which gives you that idé. >> Your many lines that the monitor is not to do any monitoring. Like: >> "Why do any monitor program need to know if the program has detached or >> not, the only thing it needs to know is the pid and the state,". > You cut out the thing after the "," which makes that a question for > someone else to fill in the blanks, the things that's not obvious > to me. I got you had a question, I did understand you had no idea why would "any monitor program need to know if the program has detached or not". Again I quote myself: «All daemons detach from the control terminal. The monitor and the daemon must coordinate each other about who's doing the detach to avoid launch time failures.» It's been obvious to all Unix sysadmins for thirty sound years, if it's still not clear to you I think I must give up. > If a process knows the pid of another process and have sufficient > rights, can it not manage that process or is there anything else it > needs to know, what am I missing ? It manages them based on what? Local config files, events transmitted, signals? You're missing the whole "monitoring" and policing the monitor does besides launching the daemon. Alessandro ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On 18/04/2017 at 14:46, k...@aspodata.se wrote: [...] > Why srvmgt_daemonize(), use -f and daemon() and you'd be fine in > either camp, end case. This is well *if* the daemon has -f and does daemon(). I know the only programs that do not do it are those that were not intended to be run as daemons, still from time to time people do that, with netcat for instance. > Why srvmgt_droppriv(), either accept that the process set's it itself > or force it to some uid:gid, what is it more to it ? "What if you do not trust the program?" (quote) Then you answered yourself already: "force it to some uid:gid": this is the monitor's job. One of them. > Why srvmgt_report_state(), just do a normal query to the process and > you'll know if it is ready to serve you or not, This way you only know that the process is up, not that "it is ready to serve you or not". I'm sure you've had experiences of processes that are running but are not delivering the services you expected from them. > if you want to know > if it is up to speed, do a benchmark, if you want to test the > integrity, do a regression test; what is it more to it ? Knowing if it is ready to serve you or not", for instance. Learning if it got stuck on something, if that is temporary or definitive, if it's best to kill it or maybe raise it's allotted max number of open files. Or just write a line in the logs and let the sysadmin pick it up and see for himself what to do. If you want an init that only launches programs and daemons and as soon forgets all about them, fine. I'm not in principle against such a minimalistic init. Just don't call it a monitor thought, 'cause it ain't. Alessandro ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On 18/04/2017 at 16:16, KatolaZ wrote: > On Tue, Apr 18, 2017 at 02:48:54PM +0100, Arnt Gulbrandsen wrote: >> kato...@freaknet.org writes: >>> Unfortunately we are already paying the consequences of badly-written >>> software implementing oddly-designed solutions to non-existing >>> problems... >> Indeed. But what's your point? >> > Oh, you are right, I didn't make it explicit: my humble opinion is > that the whole thread is not particularly interesting or useful in > this context, since all this fuss about monitoring/supervision boils > down to two alternative options: > > a) you *really* need *strict* monitoring/supervsion. In this case, > you *don't* use a unix-like operating system, since you are always > left at least with the problem of monitoring the monitor (or > supervising the supervisor). But this is not a real problem, since > in those environments where *strict* supervision/monitoring is > *really* necessary, unix-like systems are rarely used, if ever, and > the scheduler also acts as a monitor/supervisor. So if you need > *real* *strict* monitoring, the whole topic is off-topic here. I do not agree, as Linux systems are employed both in real-time scenarios (though I admit this is a really niche use case) and in High Availability infrastructures. > b) you need *loose* monitoring/supervision. In this case, you pick > and choose among what is available, or write your own. In any case, > you get a monitor/supervisor running as a user process on top of any > general-purpose operating system, possibly a unix-like one, and your > applications must still be able to deal with faults, > inconsistencies, delays, and other issues. And sometimes you will > still need manual intervention nonetheless. The "everything will be > all right" theme is just dust in your eyes, because things are never > going to be all right all the time. This is an argument that sounds as an excuse to me: "Since you'll never get perfection, just do nothing." Everyone knows that even top500 supercomputers do need some manual intervention from time to time. This is not a good reason to put the sysadmin in charge of manually managing all the processes and events that they produce. Some OS could go this way, of course, free to. But you know very well that such an OS, though philosophically and academically fine and technically elegantly constructed, is not going to win any significant market share, as today everywhere the utmost of automation is a prime requirement. > There is really no other reasonable alternative, IMVHO. Yes, there is. It's called a good compromise. Then, outside of it, you find the purists and the extremists. Alessandro ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On Tue, Apr 18, 2017 at 06:48:31PM +0200, Alessandro Selli wrote: [cut] > > > There is really no other reasonable alternative, IMVHO. > > Yes, there is. It's called a good compromise. Then, outside of it, > you find the purists and the extremists. > We have seen what an irresistible avalanche of compromises has created in the systemd camp. It turns out that I am a purist. And an extremist. And I am not at all interested in blurry concepts like "market shares", since the quest to let Linux conquest "new market shares" has only brought problems and created monsters. Get your conclusions. HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On 18/04/2017 at 19:01, KatolaZ wrote: > On Tue, Apr 18, 2017 at 06:48:31PM +0200, Alessandro Selli wrote: > > [cut] > >>> There is really no other reasonable alternative, IMVHO. >> Yes, there is. It's called a good compromise. Then, outside of it, >> you find the purists and the extremists. >> > We have seen what an irresistible avalanche of compromises has created > in the systemd camp. Today I read someone (perhaps Enrico Weigelt) stating that one of systemd's pitfalls is wanting to be the perfect init. I agree. systemd does not compromise, it wants thing to be done the way it wants, it forces all userland to comply to it's dictates. systemd is the opposite of compromise, it's dictatorial. > It turns out that I am a purist. And an extremist. This is one of the best recipies for failure. > And I am not at all > interested in blurry concepts like "market shares", If this feeling is shared by over 25% of Devuan's managers and developers, it's going to be the 1000th distribution so nice, so good, so "perfect" it's going to starve out of it's own failure to gain any significant foothold into the marketplace. You might dislike the market as much as you can, but that's what feeds projects and keeps distributions alive. Voluntary donations might get you started, but will not prop you up indefinitely into a viable OS capable of sustaining itself. > since the quest to > let Linux conquest "new market shares" has only brought problems and > created monsters. Get your conclusions. The quest to get Linux into as many lucrative markets as possible has made it what it is, that is a success, unlike worthy, perfectionist projects that failed nonetheless, like Plan9 or many of the successors to OpenSolaris. Who mentioned GNU? -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave PGP/GPG key: B7FD89FD ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
Il 18/04/2017 23:10, Alessandro Selli ha scritto: > On 18/04/2017 at 19:01, KatolaZ wrote: >> On Tue, Apr 18, 2017 at 06:48:31PM +0200, Alessandro Selli wrote: >> >> [cut] >> There is really no other reasonable alternative, IMVHO. >>> Yes, there is. It's called a good compromise. Then, outside of it, >>> you find the purists and the extremists. >>> >> We have seen what an irresistible avalanche of compromises has created >> in the systemd camp. > Today I read someone (perhaps Enrico Weigelt) stating that one of > systemd's > pitfalls is wanting to be the perfect init. Found it, it was Steve Litt instead: «There's no need to search for the perfect init or supervisor. Long ago we got a bunch of them that are all good enough, and can be combined to fill almost any need. This continuing search for a perfect init is just wheel spinning, or perhaps an excuse for profit-driven complexification.» -- Alessandro Selli Tel. 3701355486 VOIP SIP: dhatarat...@ekiga.net Chiave PGP/GPG key: B7FD89FD ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On Tue, Apr 18, 2017 at 11:10:24PM +0200, Alessandro Selli wrote: > On 18/04/2017 at 19:01, KatolaZ wrote: > > On Tue, Apr 18, 2017 at 06:48:31PM +0200, Alessandro Selli wrote: > > > > [cut] > > > >>> There is really no other reasonable alternative, IMVHO. > >> Yes, there is. It's called a good compromise. Then, outside of it, > >> you find the purists and the extremists. > >> > > We have seen what an irresistible avalanche of compromises has created > > in the systemd camp. > > Today I read someone (perhaps Enrico Weigelt) stating that one of > systemd's > pitfalls is wanting to be the perfect init. I agree. systemd does not > compromise, it wants thing to be done the way it wants, it forces all > userland to comply to it's dictates. systemd is the opposite of compromise, > it's dictatorial. > > > It turns out that I am a purist. And an extremist. > > This is one of the best recipies for failure. > It would be very good if you would like to actually contribute to Devuan :) There are lots of thigs to do, besides deciding who will fail and who will succeed. HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] apulse in experimental
Dear Devuaners, just to let you know that a .deb package for apulse is now available in experimental (except for armel: I am working on that). Just add the repo: deb http://packages.devuan.org/devuan/ experimental main to your sources.list, and then "apt-get update && apt-get install apulse" should do the trick. Then, if you want to start Firefox and force it to use ALSA, just run: $ apulse firefox-bin Same with skype and/or other packages requiring PulseAudio. I have been testing it for a while, after having removed pulseaudio, and it works fine. Please test the package and report any problem through: http://bugs.devuan.org e.g., by using the latest reportbug. HH KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] problem installing postgresql
In the middle of installing several packages using apt-get install postgresql ruby-sass I get a message. Setting up postgresql-common (165+deb8u2) ... supported-versions: WARNING! Unknown distribution: devuan /usr/share/postgresql-common/supported-versions: 64: /usr/share/postgresql-common/supported-versions: ID_LIKE: parameter not set /usr/share/postgresql-common/supported-versions: 67: /usr/share/postgresql-common/supported-versions: ID_LIKE: parameter not set Please submit this as a bug report to your distribution. Adding user postgres to group ssl-cert Evidently postgresql doesn't know about devuan. Could it be because I don't have a /etc/debian_version file, but only a /etc/devuan_version file? Or does it discover I'm using devuan by other means? -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
