SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
What benefits are there of localizing the workstation even more and making it less portable?
Localization means this:
- more work for permission settings
- more time in setting up workstation
- more work in keeping systems up to date properly
- more costly workstation PC versus low cost terminal
- less easy to lock out systems on the network
- isolated systems don't have redundancy and if loss occurs means more downtime
Networkization means this:
- less time in permission settings
- less time in system updates
- terminals only require a minimal upgrade meaning less is pushed out over the network saving bandwidth.
- easier to lock out unauthorized terminals from network services
- lower cost of terminal units versus full sized workstation
- redundancy increases loss prevention
I think people are missing the point here. The issue is not whether /bin and /lib should be merged into /usr or not. It's that udev and systemd are dependent on the contents of /usr during early boot. That is the underlying problem. The answer is to make early boot self-contained, but that will require work and it's easier for Lennart and Co to simply declare a separate /usr filesystem unsupported and ignore the fact that many sysadmins already rely on the ability to do this.
If something needs to be available during early boot, then to me the obvious place to put it would be /boot. If that means having to implement a udev-lite for early boot and then the full-function udev in /usr that takes over later when everything is in place, then so be it.
We get the advantages of all the system binaries in one place (/usr) and still get all the advantages of having it separate and shareable.
What benefits are there of localizing the workstation even more and making it less portable?
Localization means this:
- more work for permission settings
- more time in setting up workstation
- more work in keeping systems up to date properly
- more costly workstation PC versus low cost terminal
- less easy to lock out systems on the network
- isolated systems don't have redundancy and if loss occurs means more downtime
Networkization means this:
- less time in permission settings
- less time in system updates
- terminals only require a minimal upgrade meaning less is pushed out over the network saving bandwidth.
- easier to lock out unauthorized terminals from network services
- lower cost of terminal units versus full sized workstation
- redundancy increases loss prevention
I am not advocating Localization.
/usr move has benefits to both sides as well. The costs of the move are minimal if you read online about why Solaris and Fedora decided to move them.
Solaris is far from a local machine.
There is costs to everything.
Mercury... you're missing the point. The point of what Lennart and Company are wanting to do is to create a monolithic system to where it requires localization to gain access to system resources that it shouldn't without permission.
/usr is not a local system directory, it's a network extension directory the same as /opt is. In fact, /opt, /home, and /usr are the exact same directory types. A system independent directory.
The benefits of not having /usr localized are far more reaching than what I hinted at. In fact it's more secure to have less localization because less is accessible from a local machine that could be compromised.
Think about this...
How much data could you steal off a machine that has everything localized with a simple Ubuntu Live Disk.
Pretty much, everything. In fact, I hack people's broken PCs with an Ubuntu Live disk to reset lost passwords, retrieve data, and scan for malware. I can even use a tool to break through NTFS's EFS with ease.
How much data could you extract off a system that only has a read-only root file system?
Only the data that is immediately there and nothing else. And not only that, if a network permission system is setup on the local terminal, I can not access server resources.
If something needs to be available during early boot, then to me the obvious place to put it would be /boot. If that means having to implement a udev-lite for early boot and then the full-function udev in /usr that takes over later when everything is in place, then so be it.
You can include systemd in the initrd for that. I think this is now recommended over busybox init but both should work. That is obviously their preferred solution.
Quote:
Originally Posted by ReaperX7
Mercury... you're missing the point. The point of what Lennart and Company are wanting to do is to create a monolithic system to where it requires localization to gain access to system resources that it shouldn't without permission.
You could still use a PXE boot using a remote initrd that can mount a remote /usr, thus eliminating any localized content on the thin client. This is just more work.
Quote:
Originally Posted by ReaperX7
How much data could you steal off a machine that has everything localized with a simple Ubuntu Live Disk.
System data is not valuable to steal. The /usr merge does not prevent you from hosting /home and /var elsewhere, so any local theft would be relatively harmless.
I would like to mention that you do write a lot of credible stuff on LQ and I learn things from you. Sure there will be times we might disagree. I didn't want to come off at you in that type of way while writing in here. I have no hard feelings towards you. Its always good to learn from each other.
regards
Last edited by Mercury305; 08-26-2012 at 05:47 PM.
You could still use a PXE boot using a remote initrd that can mount a remote /usr, thus eliminating any localized content on the thin client. This is just more work.
Yes, and Network Admins want to cut down on work needed to reduce downtime, increase productivity, and have one less problem to stress them out. However having PXE would solve some problems but introduce others as well such as slower boot times because everything would still need to be accessed over the network and if the network is down then the system doesn't boot. If it used a localized /(root) only partition the system could be scripted also to wait at the boot process until the network becomes available such as a steady read, check, and sleep for X time if the network is down and then repeat the process.
Or even then load the local system and then have the user log in to /home using the bash terminal and load everything from /usr and such file systems upon accessing their files. The possible configurations are many.
However, you want to be able to access the right stuff at the right time, and with the right permissions, security clearances, and with the right configurations.
You could still use a PXE boot using a remote initrd that can mount a remote /usr, thus eliminating any localized content on the thin client. This is just more work.
That's true, that should fine for thin clients, and they rely on PXE already so it's not that much of a change. A bit more work, but probably not that big a deal.
Regular servers (VMs or containers) are a different story, IMHO. Today, you can have a farm of web servers running off the same shared /usr mount point, while at the same time keeping essential boot binaries local.
To me, that's as close to the ideal scenario as you can get. Moving the system binaries into /usr complicates things, and the only realistic way around it is a rather large initrd (it has to include kernel modules as well, as /lib is also supposed to move to /usr). If you're currently not using initrds at all (I'm not), this is not what I'd call a trivial change.
We'd only be doing this for one reason: systemd can't handle /usr being mounted later in the boot process. While I don't like being ambushed by developers who wish to make sweeping changes to the system that has served me well for many years, that's actually not my main issue with this proposed change. That part that scares me, is that the existence of the /usr split evidently came as a surprise to the systemd developers. There are a few books on Unix and Linux system administrations they must have missed. Like, all of them.
The fact that a daemon designed to be the ultimate solution to all things hotplug couldn't deal with /usr popping up later in the boot process, is really hilarious. Or it would be, if it hadn't caused all this trouble.
It only just now occurred to me that you think my comment was referring to you. It certainly wasn't, and I'm sorry if the context made it appear as if it was.
It only just now occurred to me that you think my comment was referring to you. It certainly wasn't, and I'm sorry if the context made it appear as if it was.
yes i realized that later. my bad. The "lazy admins" was a result to that statement and was kinda like a backlash at the wunderkind. You guys are good people. We are still on the same boat even if we may disagree on certain things.
The admins and developers need to end this friction between each other.
Developers need to listen to the admins more on specific problems instead of the Lennart way of doing things, and admins need to ask the developers more before making statements on things they don't fully understand. The end result will be better harmony for both sides.
Sorry I tought the discussion was about the fact that /bin, /lib, etc.. should be symlinked in /usr/.
As for the /usr on a separate partition, who does that anyway?
Networked systems that serve as redundancy and mirrors.
I have to say this for Lennart Poettering... I now dislike him even more as to his lack of understanding of Networked Operating Systems is now ever more so blatantly clear. His lack of knowledge in areas he is trying to change drastically is becoming ever more so profound.
What's sad is the complete and utter lack of cooperation between the different projects that make up "the Linux OS".
The systemd folks know there's an issue, but they won't work with the community to find out what needs to be moved to / in order for separate /usr to work.
The udev folks don't seem to care if they spam the /usr filesystem and that it breaks things for others.
The PCI ID database folks don't seem to care if they spam the /usr filesystem when there's consumers under / that need access to it.
And so on and so forth.
That's the nice thing about FreeBSD: it's developed as a whole, so if something is developed that needs to access resources under /usr very early in the boot sequence, then solutions to make it work are looked at.
Would it really be that hard for the systemd folks to add a "critical filesystems" checkpoint, and to add /usr to that? Every other init system out there can handle that ... except systemd it seems.
Even I'll dare to say it... Let's not push too hard on our house of cards (the fundamental GNU/Linux OS), lest the house collapse and it takes forever to rebuild everything from scratch.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.