| View previous topic :: View next topic |
| Author |
Message |
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
 Posted: Thu Jun 18, 2015 3:39 pm Post subject: |
 |
|
This reminds me of a quip I once heard about "the airplane of the future." It would be of course highly automated, and in the cockpit would be a pilot and a dog. Since the plane could fly itself and didn't really need a pilot, the pilot's main job was to feed the dog. The dog's job was to bite the pilot if he tried to take the controls.
It seems a bit parallel, here.
Occasionally one of my Linux machines throws a curve at me, but in general I feel like I'm in control. To be fair, many of my co-workers don't, and one of those things I do is help them through problems. To my credit, I'm generally able to get them working. To be fair, I tend to be a bit lost with Yum, and am somewhat more brutish than perhaps optimal.
As for Windows, I don't feel like I'm in control - I feel like I'm asking the computer to please do something for me. I'm not sure I know anyone who does feel that they're in control of their Windows computer. To be fair, I don't often ask that question, and I know a few people who might be in control. I'll have to ask, some time.
What we have here are software people who don't trust the owners of the machines their code is installed on, and want to remove anticipated problems by removing the owners ability to do anything outside of their box.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
 |
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Jun 19, 2015 1:31 pm Post subject: |
|
|
| steveL wrote: | | if you're using a chroot, then you can do what you want in that chroot (or newns). |
| mv wrote: | I can only tell from my setup without being able to tell whether this is "typical" for many systems: I have a "full" 32 bit chroot partition for my 64 bit system.
With "full" I mean: When I am in the chroot, I also want to have access to my full (outside) 64 bit system, in particular, to everything which is mounted in the (outside) /srv directory, to every USB-stick etc.
Just to mount --bind / somewhere into the chroot could not do this, because every mount after this command (e.g. of a usb stick later on) would have to happen twice: Once inside the chroot and once outside. So I am using the kernel feature of slave mounts to make the mount visible inside.
(Maybe you know a better solution for my problem? So far I do not know any.) |
OK, so to confirm: mount --rbind doesn't deal with future submounts, only those present at time of mount?
At least I understand the problem now, which I didn't before; thanks for explaining it.
| Quote: | | If now my /etc/mtab were just a file, it depends on accident whether I can shutdown my system cleanly: There are no problems if the USB-stick is umounted before the "mount --bind" is umounted. If it happens to be in opposite order, the umounting of the mount --bind fails (or has to be done --lazy which in turn can lead to other problems), and as a consequence also the 32 bit partition itself cannot be umounted cleanly. From /etc/mtab as a file this situation is not visible, because this file knows nothing about slave mounts. |
Well this is what I meant by "you can do what you want in a chroot"; in the sense that I've scripted this situation, and it's easy enough to do the unmounts in reverse order in bash (or any shell with integer-indexed arrays). So you just trap on EXIT (which we do already) and run the (remaining) unmounts no matter what happens (barring a KILL, as ever.)
We needed a sleep 1 between umounts, so that eg: /usr/local/portage was properly disconnected before umount of /usr/local (to avoid the "fs busy" error you mention.) Though no doubt you're working in perl ;)
| Quote: | | I would have no problem if /etc/mtab would contain also the slave mount information. But util-linux is dropping more and more the support of /etc/mtab as a file (that's why I said: systemd is only the messenger in this case). |
Well the mount documentation needs updating then. Or my machine does ;) Though see below, as I don't think we have anything like a reasonable solution yet.
| Quote: | | Moreover, I do not see why proper container support (although I do not need it in my situation) should be a red herring: |
That's the kind of elision I really hate; no-one said "proper container support" (in and of itself) is a red-herring so you are twisting my words here, at least in effect. Merely that I don't see what the issue is with mounts, given that you are running a container.
It's a simple misunderstanding, as I did not know what the problem was; granted that's my ignorance, but that's what discussion is for: to get the problems laid out simply and clearly, without regard to any possible implementation of a "solution."
In this case, if you are running a container, what does it mean exactly? My usual understanding of it is as similar to a virtual machine, in that it has initscripts, if not the whole shebang. We've all seen the restriction on container support of various kinds in openrc runscripts, for instance.
If you're doing all that, you really have no excuse for not simply dealing with those mounts in an initscript, afaic, in a similar vein to a chrooting script-pair.
It's not hard, is it?
| Quote: | | If you rely on the kernel to reflect the true situation (for your namespace), both problems are solved simultaneously, so it seems to be the cleaner thing to fix the kernel (or whoever is responsible for this) to put all mount flags in /proc than to fix util-linux to support slave mounts (and still not being sure to have the "true" situation in /etc/mtab and still not being able to handle containers correctly). |
Just seems to be rather ludicrous if the answer is to reinvent /etc/mtab via /run/utab combined with /proc/self/mounts. All you've done is make things more complex to end up with a more unwieldy "solution".
As pointed out what can seem like a reasonable approach is not necessarily a good solution; those typically take some ironing-out over time with experience; but most of all they require some adequate testing in real-world scenarios before you push it to end-users, not this continuous alpha-level idiocy.
As stated, I have no issue with it if the new approach reflects the same information; but it clearly does not. Since you stated it's been around for 10 years or so, I'm at a loss as to why it's still not resolved. I thought the kernel was worked on by 70% professionals these days.
The argument about "oh my, a file in /etc changing *swoon*" seems rather bogus to me, as well, considering /etc/resolv.conf.
Can't you nuskoolers with all your fancy new filesystems sort out read-only root without having to change everyone else's code around? If not, then you're not half as elite as you think, afaic: as that's just a cop-out, pure and simple.
But fine, /run is the new writeable /etc, even though /etc has always been writeable (or HTF are you going to configure your machine), because RedHat, and because we can't simply sort out a decent overlay/union fs when we actually require a read-only root, which none of us here do, afaict. *sigh*
I think what it comes down to is whether you're trying to do a "one-size-fits-all-for-every-situation" all-encompassing "solution" for a locked-down consumer, or whether you're developing software for sysadmins.
I prefer the latter, as admins can deal with the end-user much more effectively than any coder sitting on the other side of the world in his pyjamas, merely speculating as to the specific situation without any real clue.
If One True Way worked, we'd all be on Windows and happy about it. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Jun 19, 2015 1:53 pm Post subject: |
|
|
| depontius wrote: | | What we have here are software people who don't trust the owners of the machines their code is installed on, and want to remove anticipated problems by removing the owners ability to do anything outside of their box. |
Indeed; the reason they don't trust them is because they're a product, like a factory chicken, not the customer they sell to directly (which would be other corporates seeking a dribble of the income-stream the chickens represent.)
They don't let the battery hens decide what kind of locks go on the factory door.
This is the culmination of 30 years obfuscation by large companies, of the plain and simple approach to coding that is the only one which works over time.
Obfuscation for the sake of justifying make-work has become a pretext to keep consumers dumb ("don't worry your pretty little head about it, look: shiny!")
Ultimately though, you have to get the job done, and there the UNIX tradition of craft wins out every time. |
|
| Back to top |
|
|
saellaven
l33t
Joined: 23 Jul 2006
Posts: 646
|
| Posted: Fri Jun 19, 2015 2:55 pm Post subject: |
|
|
| steveL wrote: |
I think what it comes down to is whether you're trying to do a "one-size-fits-all-for-every-situation" all-encompassing "solution" for a locked-down consumer, or whether you're developing software for sysadmins.
I prefer the latter, as admins can deal with the end-user much more effectively than any coder sitting on the other side of the world in his pyjamas, merely speculating as to the specific situation without any real clue.
If One True Way worked, we'd all be on Windows and happy about it. |
Which is one of the reasons I migrated to Linux 20ish years ago... precisely, because it didn't force a one-size-fits-all solution on me. Linux could be whatever I needed it to be and, by the late 90s, it literally was just that, with me abandoning distributions completely and rolling my own from scratch before there was a LFS 1.0 (in fact, I remember passing a tip to use a chroot to them before they released). I switched to Gentoo a decade ago to automate what I was already doing because Gentoo was flexible enough at that time (though it is getting less flexible and more one-size-fits-all with people like williamh around).
I abandoned the Microsoft world because I didn't want a OSFA platform dictating what I could do and what my workflow had to be. I abandoned GNOME when 2.0 came out and took away a ton of features and finally came back to it around 2.12 once basic functionality had been added back to it, only for them to get even worse with 3.0 when I abandoned it again. I left Netscape for Firefox, only for Firefox to become a bigger pig than Netscape was despite not dragging a suite along with it, and have left Firefox for Palemoon.
The new generation of people raised on Windows trying to force Linux into the Windows mindset, as well as RedHat for trying to capitalize on this idiocy so they can become the one true distribution that rules them all, have decided that they know what is best for all of us, when it's obvious that, at a simple glance, they don't even know what it is THEY want, much less can they foresee the need for flexibility to allow others to operate outside of their myopic vision.
I fully expect Gentoo to roll over and become just another inflexible RH clone if williamh and friends have their way... at which point, I'll go back to rolling my own systems from scratch or move to BSD. If it means I'm no longer "modern" (their code word for accepting their dog food), so be it. Their motto: you can do it your own way, if it's done just how I say. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sat Jun 20, 2015 3:13 pm Post subject: |
|
|
| steveL wrote: | | [OK, so to confirm: mount --rbind doesn't deal with future submounts, only those present at time of mount? |
Yes. mount --rbind is the same as calling mount --bind several times.
| Quote: | | Well this is what I meant by "you can do what you want in a chroot" [...] So you just trap on EXIT (which we do already) and run the (remaining) unmounts no matter what happens (barring a KILL, as ever.) |
There are two basic philosophies how you can deal with such a chroot:
1. You prepare/mount it for a particular command, and at the end you umount it.
2. You mount it at start and umount it at stop. (This is what I meant by "full" chroot)
Case 1 is useful if you only occassionally run a limited set of commands in the chroot, and only successively. Case 2 is useful if you run "randomly" a lot commands in the chroot, often in parallel to other programs, etc., roughyl speaking if during usage you do not want to care whether you need to run something in the chroot or in the main system.
| Quote: | | We needed a sleep 1 between umounts, so that eg: /usr/local/portage was properly disconnected before umount of /usr/local |
I also had such a type of problems and think that such things are rather unclean: In a "correct" setup you should not need to call sleep (one of the problems with sleep is that any amount of time can be too less if e.g. the machine is just swapping or whatever).
In fact, I think that one of the main ideas of systemd is to handle case 1 properly: The "guiding" process who should umount when everything in the chroot is finished (and actually also can mount in the moment when you enter the chroot) is part of systemd. This is indeed one of the few things which are perhaps "correct" to approach by a "system daemon".
I do not know whether the systemd approach for this is really good, since I never used it: In fact, I want to have Case 2 and not case 1.
| Quote: | | If you're doing all that, you really have no excuse for not simply dealing with those mounts in an initscript, afaic, in a similar vein to a chrooting script-pair. |
This is useful only for case 1.
| Quote: | | even though /etc has always been writeable |
I cannot find the reference in the moment, but I am rather sure that /etc is not required to be writable at run-time.
| Quote: | | (or HTF are you going to configure your machine) |
There are quite some use-cases where you don't have to. Especially in some VM maybe you do not even want that the user can do this easily (even if he should get root permissions by some backdoor): In such use-cases, you write it once but not want to mount it writable.
I agree that this is not a good idea for whole machine, but it is a good idea when e.g. you want to start your browser with limited permissions in a jail which is as isolated as possible...
Also, having /etc non-writable can make sense for certain reascue CDs. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Jun 20, 2015 3:37 pm Post subject: |
|
|
| steveL wrote: | | [OK, so to confirm: mount --rbind doesn't deal with future submounts, only those present at time of mount? |
| mv wrote: | | Yes. mount --rbind is the same as calling mount --bind several times. |
Ok.
| Quote: | | In fact, I think that one of the main ideas of systemd is to handle case 1 properly: The "guiding" process who should umount when everything in the chroot is finished (and actually also can mount in the moment when you enter the chroot) is part of systemd. This is indeed one of the few things which are perhaps "correct" to approach by a "system daemon". |
Oh please, the "guiding process" is the outer script which has setup the chroot and called into the lower of the script pair, if the user didn't just want to drop to bash.
Nothing else is going on at that point, and the single-second sleep is just to give the fs caches time to flush.
When I reviewed the script, I was quite surprised to see it, as I didn't even recall it delaying.
Thanks for saying I'm handling it properly though, although we already knew that ;-)
| Quote: | | I do not know whether the systemd approach for this is really good, since I never used it: In fact, I want to have Case 2 and not case 1. |
Trust me, you can do both quite easily from a bash script pair. I know, I've done exactly that for the installer we did 6 or 7 years ago; dropping to a shell happened whenever something went wrong it couldn't handle, and I used to drop to shell by choice whenever I liked.
| steveL wrote: | | even though /etc has always been writeable (or HTF are you going to configure your machine) |
| Quote: | I cannot find the reference in the moment, but I am rather sure that /etc is not required to be writable at run-time.
There are quite some use-cases where you don't have to [configure your machine]. Especially in some VM maybe you do not even want that the user can do this easily (even if he should get root permissions by some backdoor): In such use-cases, you write it once but not want to mount it writable.
I agree that this is not a good idea for whole machine, but it is a good idea when e.g. you want to start your browser with limited permissions in a jail which is as isolated as possible...
Also, having /etc non-writable can make sense for certain rescue CDs. |
The jail-case is not /etc, it's some /path/to/jail/etc and as discussed you can do what you want in there, which is the point of them.
The rest are all specialist use-cases, and definitely not reasons to wag the dog, simply reasons to configure your setup how you want. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sat Jun 20, 2015 4:40 pm Post subject: |
|
|
| steveL wrote: | | Oh please, the "guiding process" is the outer script which has setup the chroot and called into the lower of the script pair, if the user didn't just want to drop to bash. |
This solution has some problems when called several times for several processes. These problems can partially be avoided by using lock files, but then things very quickly become very complex if you want to avoid races, and you start reinventing communication protocols on a file level.
What is more severe is that you cannot guarantee that the "closing" script is always called when the inner process dies: As a very simple example consider the (admittedly unlikely but nevertheless possible) case that the kernels OOM shoots your outer process. Also, if your inner process should hang, you have a severe problem at shutdown...
| Quote: | | The jail-case is not /etc, it's some /path/to/jail/etc and as discussed you can do what you want in there, which is the point of them. |
Rather likely you will want to mount /etc there. Only /etc/mtab is the only obstacle to do this.
| Quote: | | The rest are all specialist use-cases, and definitely not reasons to wag the dog |
Since /etc/mtab is the only file requiring write-access of /etc - who is wagging the dog? |
|
| Back to top |
|
|
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2034
Location: United Kingdom
|
| Posted: Sat Jun 20, 2015 6:17 pm Post subject: |
|
|
| depontius wrote: | | As for Windows, I don't feel like I'm in control - I feel like I'm asking the computer to please do something for me. |
I feel that way with udev. But perhaps I'm just jaded after the problems it has caused me over the last few years.
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.
Fitzcarraldo's blog |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Jun 20, 2015 8:20 pm Post subject: |
|
|
| steveL wrote: | | Oh please, the "guiding process" is the outer script which has setup the chroot and called into the lower of the script pair, if the user didn't just want to drop to bash. |
| mv wrote: | This solution has some problems when called several times for several processes. These problems can partially be avoided by using lock files, but then things very quickly become very complex if you want to avoid races, and you start reinventing communication protocols on a file level.
What is more severe is that you cannot guarantee that the "closing" script is always called when the inner process dies: As a very simple example consider the (admittedly unlikely but nevertheless possible) case that the kernels OOM shoots your outer process. Also, if your inner process should hang, you have a severe problem at shutdown... |
Make up your mind; either you're sitting there at your terminal trying to do all kinds of "normal" work (which involves mounting random drives here and there inside your jail), or you're not.
If you are, then by definition you're at your machine to deal with these things.
You keep moving the goalposts, and suddenly your interactive situation has to cope with the same issues as a multi-scripted setup. If it's really scripted, with processes deciding to drop to a chroot(!), you're not mounting random drives at will, because it's not you sitting there interactively.
| Quote: | | Quote: | | The jail-case is not /etc, it's some /path/to/jail/etc and as discussed you can do what you want in there, which is the point of them. |
Rather likely you will want to mount /etc there. Only /etc/mtab is the only obstacle to do this. |
Wait, what? No, rather likely I don't want to expose my root hardware configuration to a jail, especially since we're discussing sexy random chroots from various processes that we're not actually initiating directly as a user.
| Quote: | | Quote: | | The rest are all specialist use-cases, and definitely not reasons to wag the dog |
Since /etc/mtab is the only file requiring write-access of /etc - who is wagging the dog? |
*sigh* the dog you're wagging is normal usage. You know: all those non-esoteric setups like us sitting here at our desktops, or admins logging into servers they administer.
I'm not saying slave mounts should be invisible to the top-level, nor am I saying you want $ROOT/etc/mtab to be anything other than a symlink to /proc/self/mounts when in a container.
I'm saying what I said above: if the "solution" is to reinvent /etc/mtab as a combination of /proc/self/mounts and /run/utab, it sucks. |
|
| Back to top |
|
|
ulenrich
Veteran
Joined: 10 Oct 2010
Posts: 1480
|
| Posted: Sat Jun 20, 2015 9:34 pm Post subject: |
|
|
| depontius wrote: | | As for Windows, I don't feel like I'm in control - I feel like I'm asking the computer to please do something for me. I'm not sure I know anyone who does feel that they're in control of their Windows computer. To be fair, I don't often ask that question, and I know a few people who might be in control. I'll have to ask, some time. |
For sure Windows2000 had one of the best systemd of that era. But nobody used it. It simply was empty. Like their Winnt Unix layer was one of the best, but obviously no demand of it. A better Unix standard than most of the other proprietary Unices. Which exactly was the driving force for Linux to develop.
Using Cygwin and Colinux alike I changed to Debian thinking to find some better used Unix there. Just to find a very chaotic init.d hackery without any clean thought about it. Discovery of Gentoo using openrc relieved me a bit. But there had to be years of discussion go by until it was clear what a network dependency should mean 
For me no surprise the Linux crowd would follow someone who looked up the principles of launchD and fully understood them. A successful usage is the AppleWatch working together with an iPhone: That what is to come! A rather poor example it was we will think in a few years as the complexity will exponentially grow having a multitude of devices working together.
By the way Apple lacks a secured kdbus like mechanism:
https://blog.agilebits.com/2015/06/17/1password-inter-process-communication-discussion/ |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sun Jun 21, 2015 12:03 pm Post subject: |
|
|
| steveL wrote: | Make up your mind; either you're sitting there at your terminal trying to do all kinds of "normal" work (which involves mounting random drives here and there inside your jail), or you're not.
If you are, then by definition you're at your machine to deal with these things. |
Surprise! I'm at a machine and expect that it is doing the routine work for me (like doing an automatic second mount so that I can use the USB stick inside the chroot without mounting it manually tice).
| Quote: | | You keep moving the goalposts |
No, I claimed my goal from the very beginning: I want a "full" chroot which I can enter anytime without having to care about anytihng else and everything visible inside always.
You started to move this goalpost by talking about script-pairs. These can solve a different problem (which I explicitly distinguished with 1 and 2).
Nevertheless, I agree that there is more than one interesting goal, and a discussion about the right handling of /etc/mtab should not exclude either of these:
1. Your setup (numbered 1 already in my previous post).
2. The "full" chroot setup (numbered 2 already in my previous post).
3. The security-driven jail setup (e.g. to run a browser in an environment as isolated as possible).
I was mainly discussing 2 which can be done by using mount --make-shared in startup scripts and having /etc/mtab a symlink.
I do not have so much experience with 1 (except trying this first as a substitute for 2 and being unsatisfied with it): From my experience the problem of a process not finishing or being killed is serious - so for 1, I consider indeed a "system daemon" approach more appropriate than a wrapper script (or script-pair) solution, since I have seen several shortcomings in the latter which cannot be avoided easily. However, this brings us to a completely different topic which I do not want to discuss in length now - mainly due to lack of time in the moment. The last poitnt 3 is similar to 1; the main difficulty is to umount reliably.
| Quote: | | If it's really scripted, with processes deciding to drop to a chroot(!), you're not mounting random drives at will, because it's not you sitting there interactively. |
I want to sit there and do my work and not think about whether I need to mount something into a chroot or wait for anothre process to be finished: I just want to start siomething inside e.g. a chroot shell and expect that the setup is such that things will just work this way. And if I shuold forget to log out of the chroot shell before shutting down the machine, I expect that all drives are guaranteed to be umounted cleanly anyway.
| Quote: | | Wait, what? No, rather likely I don't want to expose my root hardware configuration to a jail, especially since we're discussing sexy random chroots from various processes that we're not actually initiating directly as a user. |
Surprise! If you want to hide certain mounts in the chroot using namespaces, it is even better to have a non-static /etc/mtab!
And now it is again you who moves goalposts: You are talking about 3 which is not necessarily the main intention of 1 and even less of 2. The reason for 2 is to be able to use a full alternative system (here: 32 bit with someother USE-flags) in parallel (for building, testing, ...).
| Quote: | | *sigh* the dog you're wagging is normal usage. |
Not recommended usage since many years which caused a completely unjustified exception of being able to mount /etc read-only.
| Quote: | | You know: all those non-esoteric setups like us sitting here at our desktops, or admins logging into servers they administer. |
You mean for all those purposes for which it makes absolutely no difference whether /etc/mtab is a symlink or a file. Well, except that being a symlink mirrors guaranteed the real situation and thus would be preferrable anyway.
| Quote: | | I'm saying what I said above: if the "solution" is to reinvent /etc/mtab as a combination of /proc/self/mounts and /run/utab, it sucks. |
Fact is that /etc/mtab always sucked: Not necessary mirroring the correct situation and being the only file required to be writable in /etc to boot a machine. So almost any workaround is better, 'though I agree that it would be better if /proc/self/mounts would contain all information which were previously in /etc/mtab. On the other hand nfs is perhaps an exotic enough use case to justify a separate extra handling. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Jun 21, 2015 3:58 pm Post subject: |
|
|
@mv: I don't see where picking each other's posts apart is getting us, so I'm going to step back: it seems to me that there's different use-cases.
The reliability of a script pair, that I've had zero trouble with doing installs, when you're interactive, is reasonable. The calling process isn't using lots of RAM, and the OOM might just as easily kill your "system daemon" (especially if it's a bloated hog) for what you admit is an unlikely scenario.
In this case the delusionally-perfect is indeed the enemy of the good enough. After all, a daemon is simply a userland process.
In any event, the use-cases don't matter that much; what matters is having an accurate /etc/mtab, whatever name/s you give it.
Moving to /run/mtab would have made more sense to me, given that /run is the new /srv.
I haven't looked at util-linux code to know what changes they haven't bothered to put in; if it works well enough, no-one really cares anyhow.
I do wonder how your putative user is going to deal with things like /etc/portage/make.conf; you also ignored the point about /etc/resolv.conf, but it's not a use-case I find interesting. When I do, I'll do it properly, without expecting every other scenario to have to fit mine. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sun Jun 21, 2015 6:22 pm Post subject: |
|
|
| steveL wrote: | | given that /run is the new /srv |
I guess that you meant /var instead of /srv? |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sun Jun 21, 2015 6:30 pm Post subject: |
|
|
| steveL wrote: | | After all, a daemon is simply a userland process |
This is one of the very few reasons why the PID 1 of systemd indeed made sense to me when I first heard about it: For such a daemon to be "stable" enough, you should really be as close to the kernel as possible. Of course, this reason should not be used as an excuse to shuffle all sort of other nonsense to PID 1, too, as systemd does. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Jun 22, 2015 4:01 pm Post subject: |
|
|
| steveL wrote: | | given that /run is the new /srv |
| mv wrote: | | I guess that you meant /var instead of /srv? |
No, I meant what I said; having somewhere writeable that daemons could use that was not on another partition, for exactly the reasons we have /run, was the original point of djb's /srv.
I recall a few of us were disappointed Linux didn't just adopt the existing art. But then pointless reinvention and renaming seems to be the order of the "modern" day.
| steveL wrote: | | After all, a daemon is simply a userland process |
| mv wrote: | | This is one of the very few reasons why the PID 1 of systemd indeed made sense to me when I first heard about it: For such a daemon to be "stable" enough, you should really be as close to the kernel as possible. Of course, this reason should not be used as an excuse to shuffle all sort of other nonsense to PID 1, too, as systemd does. |
What reason; that you're worried it's going to get OOMed? Lul.
Personally I prefer the separation, and to always run checks, and eg local.stop at shutdown.
If your "system daemon" (christ: be honest. Your Master Control Program) has failed you can still shutdown and do whatever else.
That's the point of a minimal backstop for the admin, whom all this is aimed at, remember?
ATM it appears like you are unaware that pid1 was needed for the admin, before anyone decided to reparent zombies to it.
As for a userland process being "close to the kernel", words fail. The contradiction in terms is laughable. (kthreads aren't cogent either.)
Does the OOM seriously have so little regard for privilege?
Might want to fix that instead of using it as a pretext for all this nonsense, if it really matters in these days of 8-16GB being considered minimal (!)
Or y'know, not use such an insanely bloated and tentacled piece of crap. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Mon Jun 22, 2015 6:10 pm Post subject: |
|
|
| steveL wrote: | | mv wrote: | | I guess that you meant /var instead of /srv? |
No, I meant what I said; having somewhere writeable that daemons could use that was not on another partition, for exactly the reasons we have /run, was the original point of djb's /srv. |
I don't care what perhaps historically was the original point of a directory 20 years ago. According to FHS, /srv is a completely diferent thing, and putting /var/run or /run data there would be completely wrong: /srv is the place where e.g. you might have stored multimedia files, huge databases or other similar long-living things. A daemon writing local data there (and expecting that it be cleaned on booting) is quite the opposite of this... |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Jun 22, 2015 6:27 pm Post subject: |
|
|
| mv wrote: | | I guess that you meant /var instead of /srv? |
| steveL wrote: | | No, I meant what I said; having somewhere writeable that daemons could use that was not on another partition, for exactly the reasons we have /run, was the original point of djb's /srv. |
| mv wrote: | | I don't care what perhaps historically was the original point of a directory 20 years ago. According to FHS, /srv is a completely diferent thing, and putting /var/run or /run data there would be completely wrong: /srv is the place where e.g. you might have stored multimedia files, huge databases or other similar long-living things. A daemon writing local data there (and expecting that it be cleaned on booting) is quite the opposite of this... |
That would be /var instead of /srv, as you said above.
That's precisely what it was meant for, eg: /var/www, or: /var/db.
What random-joe cares to do 15 years after the event, without even paying mind to the intended purpose of those "old fences" (in Chesterton's terms), is neither here nor there when it comes to design: we must still understand them too, or we simply repeat history and reinvent the wheel (or in this case the carburettor, or something.)
As here, reinventing /srv as /run, because someone "doesn't care what happened 20 years ago," iow doesn't care about prior craft, and is apparently incapable of understanding the purpose of /var, so has configured their distribution to dump loads of inappropriate data in /srv. So let's make another /srv, and another mtab, and call each addition and replication "progress" or "innovation" when it looks more like floundering in the shoals of self-inflicted ignorance.
"A lack of basic research," as my boss would say. That it's in the FHS says more about standardisation processes than anything else, afaic: the ones which are good, like C and POSIX, are the exceptions which prove the rule.
*shrug* plus ca change. (imagine a cedilla there if it bothers you. ;) |
|
| Back to top |
|
|
uudruid74
n00b
Joined: 21 Jun 2014
Posts: 30
|
| Posted: Mon Jun 22, 2015 7:43 pm Post subject: |
|
|
| Naib wrote: |
That's a sample of one, anecdotal evidence.
Take me for instance, at work I daily use USB memory sticks to transfer data from scope or use a piece of hardware I designed for interrogating controller cards (ftdi chip back end)
At home I am using USB for mass storage or to access an arm cortex mbed card as I sort out a python interface to a CDC device (to replace the pods used at work with a cheaper and more capable platform) |
I plug in my phone(s), USB fans, keyboard/mouse receiver, TV Tuner, external sound card, graphics tablet, and sometimes a bluetooth adapter, and various USB flash drives. The phones generally do USB debugging (Android ADB), MTP for file storage, and with a tap of the phone they do USB networking - great for high-speed reliable networking to share the phone's internet connectivity (Wireless is an option, but I prefer wired for security and speed - plus my wireless card has known issues with Linux and tends to flake out randomly).
So .. USB is not a niche for me. I'm dead in the water without it. The fact that this all integrates seamlessly with Gnome is a must. I tap the USB Networking button on my phone's pulldown and I can visually see my phone's filesystem vanish from the list of "Places" and I get a pop-up that USB Networking is up and active. Tap it again, and the popup says its disabled/down and my phone's filesystem reappears. I don't have time to fiddle with stuff. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Tue Jun 23, 2015 11:05 pm Post subject: |
|
|
| steveL wrote: | | mv wrote: | | I guess that you meant /var instead of /srv? |
| steveL wrote: | | No, I meant what I said; having somewhere writeable that daemons could use that was not on another partition, for exactly the reasons we have /run, was the original point of djb's /srv. |
| mv wrote: | | I don't care what perhaps historically was the original point of a directory 20 years ago. According to FHS, /srv is a completely diferent thing, and putting /var/run or /run data there would be completely wrong: /srv is the place where e.g. you might have stored multimedia files, huge databases or other similar long-living things. A daemon writing local data there (and expecting that it be cleaned on booting) is quite the opposite of this... |
That would be /var instead of /srv, as you said above. |
Now you start interpreting the directories in a manner which really doesn't make sense at all:
You claim now that /var is for permanent data like stored multimedia files (which according to FHS is /srv).
You claim that /srv is for temporary files and runtime data (which according to FHS is /tmp or /var/tmp or /var/run or /run).
And quite some other nonsense like that distributions would store data in /srv. (BTW: If gentoo would store data in /srv unrequested, I would immediately file a bug report; if this severe bug would not be fixed, I would probably quit using gentoo).
| Quote: | | What random-joe cares to do 15 years after the event, without even paying mind to the intended purpose of those "old fences" (in Chesterton's terms), is neither here nor there when it comes to design: we must still understand them too, or we simply repeat history and reinvent the wheel (or in this case the carburettor, or something.) |
What some historic machine did 20 years ago really does not matter anymore. FHS is a well-established and well-thought standard. If you do not like something about this standard, you complain comes abuot 15 years too late.
Hint: You may consider /var as something else as "variable", but you will not find an argument which will convince me to consider it differently - nor probably you will convince anybody else with such a nonsense.
| Quote: | | "A lack of basic research," as my boss would say. |
For your claims, I would say: A lack of common sense... Even if research should turn out that /var on some prehistoric machine meant "local source for persistent data", the first thing I would do is to change this nonsense and look for a sane directory for it. Which apparently people have done 15 years ago or so, when they developed FHS. |
|
| Back to top |
|
|
uudruid74
n00b
Joined: 21 Jun 2014
Posts: 30
|
| Posted: Tue Jun 23, 2015 11:44 pm Post subject: |
|
|
| mv wrote: | | steveL wrote: | | After all, a daemon is simply a userland process |
This is one of the very few reasons why the PID 1 of systemd indeed made sense to me when I first heard about it: For such a daemon to be "stable" enough, you should really be as close to the kernel as possible. Of course, this reason should not be used as an excuse to shuffle all sort of other nonsense to PID 1, too, as systemd does. |
Just my 2 cents, but PID 1 isn't any closer to the kernel than PID 2000. Being PID 1 doesn't give any special privalege or make it any more "stable". What it does is reboot your system if it ever exits. Thats all. If it dies, it takes the whole system with it.
Now, the reverse is true. If it runs as PID 1, it had BETTER be stable, but being PID 1 doesn't MAKE it stable. Being small, simple, and devoid of extra crap would spell stable. Let it run forever and let other processes do the work. Hey wait ... thats the traditional UNIX way! Systemd is ... NOT |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Wed Jun 24, 2015 12:30 am Post subject: |
|
|
There are a few other characteristics of PID-1...
It's the default parent for processes, notably daemons that double-exec to be emancipated from the process that spawned them. As such, only PID-1 can be notified if the daemon dies, anyone else has to poll.
Only PID-1 can un-drop system-wide capabilities. Many years ago, on my server, I looked at using chattr to make my active logs appendable and old logs immutable, then drop the chattr capability. But then you can't do log rotation. It was of insufficient benefit to try writing my own PID-1, but it would be nice if it could happen.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
uudruid74
n00b
Joined: 21 Jun 2014
Posts: 30
|
| Posted: Wed Jun 24, 2015 1:35 am Post subject: |
|
|
| depontius wrote: | There are a few other characteristics of PID-1...
It's the default parent for processes, notably daemons that double-exec to be emancipated from the process that spawned them. As such, only PID-1 can be notified if the daemon dies, anyone else has to poll.
Only PID-1 can un-drop system-wide capabilities. Many years ago, on my server, I looked at using chattr to make my active logs appendable and old logs immutable, then drop the chattr capability. But then you can't do log rotation. It was of insufficient benefit to try writing my own PID-1, but it would be nice if it could happen. |
Yes and no. There are other solutions but they require the daemon to be written differently so that the parent gets notified. But, requiring apps to change how they've been written and ignore Unix conventions is the job of systemd. Messing with logs is the job of the syslog daemon, couldn't you hack it to do what you need? If it doesn't already support it.
-- Evan |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Wed Jun 24, 2015 3:32 pm Post subject: |
|
|
| uudruid74 wrote: | | Messing with logs is the job of the syslog daemon, couldn't you hack it to do what you need? If it doesn't already support it. |
I normally run syslog-ng, and have cron run logrotate. That is all normal.
Years back I had been thinking about an extra layer of security, with the chattr stuff. If it were just a matter of making logs append-only and old logs immutable, you're correct, that's the kind of thing that could be hacked into syslog-ng and logrotate. However at that level, it's only a very minor speed-bump of a security addition, because root can undo the chattr -i/-a, tamper with the logs, then redo the chattrs..
If you fiddle with the "capabilities bounding set" you can make it so nobody, not even root, can do the chattrs. At that point your logs can have more real safety. But because you've now given up - systemwide - the ability to run chattr, you can't do proper log rotation. That's where PID-1 comes in, because while any root process can reduce the capabilities bounding set, only PID-1 can increase it - only PID-1 could get back the ability to run chattr so logrotate can do its stuff.
To be fair, I need to see what other capabilities are lumped in with chattr, because that may make it impossible to run the system. The whole idea may be borked from the start. I had only viewed it as an incremental security improvement anyway, just like module signing on my last kernel build.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Jun 24, 2015 5:11 pm Post subject: |
|
|
| mv wrote: | | I don't care what perhaps historically was the original point of a directory 20 years ago. According to FHS, /srv is a completely diferent thing, and putting /var/run or /run data there would be completely wrong: /srv is the place where e.g. you might have stored multimedia files, huge databases or other similar long-living things. A daemon writing local data there (and expecting that it be cleaned on booting) is quite the opposite of this... |
| steveL wrote: | | That would be /var instead of /srv, as you said above. |
| mv wrote: | Now you start interpreting the directories in a manner which really doesn't make sense at all:
You claim now that /var is for permanent data like stored multimedia files (which according to FHS is /srv). |
It's funny how you only mention "multimedia files" now, when it was also about "huge databases" before.
Since you didn't concede the obvious: files and data in /var are what we cannot control the size of, at a distribution level, what we serve like "huge databases" (/var/db), and /var/www.
It is down to the local admin to partition as they choose; the point is they know that /var is where their system-wide datasets live.
That includes datasets from "system apps": also "theirs" in the sense that it's data generated by their usage, and they should know what programs they have running system-wide; there's no real difference between portage and apache in that sense.
Certainly a decent admin is aware of those, and everyone else can learn by seeing what subdirs their programs are creating, on their behalf.
| Quote: | | You claim that /srv is for temporary files and runtime data (which according to FHS is /tmp or /var/tmp or /var/run or /run). |
As I said: | steveL wrote: | | having somewhere writeable that daemons could use that was not on another partition, for exactly the reasons we have /run, was the original point of djb's /srv. |
You don't care about what it was meant for, even though you want to claim designB is superior to designB: only what it's supposedly been used for ie a duplication of /var, likely based on the naming.
| Quote: | | And quite some other nonsense like that distributions would store data in /srv. |
Someone had to configure those services to access and store their data in /srv, rather than /var as expected, and as we've seen all that does is duplicate what /var is already meant for: potentially ballooning data storage, which it is the admin's job to keep an eye on.
So now the admin has two variant partitions to watch, and the daemon-writers have lost /srv as it was meant to be, but never mind, now we have another /srv too, so that's all good. /s
The rest is just bile, so I'll ignore it.
In summary: explain /var/www then.
Hope you're well, man. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Thu Jun 25, 2015 5:38 am Post subject: |
|
|
| uudruid74 wrote: | | Just my 2 cents, but PID 1 isn't any closer to the kernel than PID 2000. Being PID 1 doesn't give any special privalege or make it any more "stable". |
Well, first, you can be sure that the kernel's OOM will not kill PID 1. So it is more stable than any other process. Second, this is the only process which gets assigned children which would otherwise be zombies. So it also has special privileges. Both you do want to have to umount a chroot reliably. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
