Location of some executables

briaeros007 briaeros007 at gmail.com
Wed May 11 07:34:32 EDT 2011


2011/5/11 Gordan Bobic <gordan.bobic at gmail.com>:
> On 05/11/2011 09:07 AM, briaeros007 wrote:
>>
>> Hello,
>>
>> To add fuel to the fire.
>>
>> /usr can be farily sized (mine do 7.6 Go, /bin and /sbin do 22M...).
>>
>> you can want to have a little "/" partition  for different reason :
>> - quota things (you doesn't want your / full only because you've
>> install a soft which copy 5 Go on /usr/share
>
> You have a quota in / ??
>
on /usr.

>> - you can choose to have your / read only (system maintenance) and
>> your /usr read write (add/modification of software)
>
> So following that logic, if you then also separate out /var, you have a
> situation where your package DB is listing packages on multiple different
> partitions. That just strikes me as a bad idea.
>
And why that ?

Package db already manage
/boot
/etc
/bin - /sbin
/lib
/usr
/usr/local
/opt
/var

And if you said that all theses directory are in the same partition
(and particulary /boot and / ) ...


> Apps are generally small. Data is generally big. I am all for putting data
> onto separate volumes, but when the entire OS install + apps is smaller than
> the amount of RAM on mid-range graphics card, I don't really see the gain of
> splitting it up in the general case.
>
Apps aren't small.
If i install a Business Object, I must have  got 5 Go of free space to
install it. Yes 5 Go.
If i play with BMC remedy, it's the same idea. And data are in db.

Everybody doesn't use their system only as a desktop.


>> - boot pxe for the system (one nfs share for the core system, and
>> other for applications which are loaded when the system initialize
>> itself).
>> - etc...
>
> Sounds like an administrative nightmare. What commonly available package
> management system will cope with that?
>
If you can't follow multiple nfs share, well pxe isn't for you.
What commonly available package management system manage pxe ? none.
I'm talking about specific need due to a boot procedure, and you talk
about package management system. I don't see the links.

>> /bin and /sbin are here for a reason : to provide a lightweigth
>> environnement who can be used to manage the server, even if other
>> partitions can't be mounted.
>> I think It's a best practice to separate things on a server. if
>> something bad happen, the other things aren't impacted.
>
> The chances are that you're not going to get very far in fixing things
> without the things in /usr/bin and /usr/sbin.
>
So you're just saying that generations of sysadmin are just dumbass
and protection/compartimentalization aren't useful ?
Let's just put all the things inside a big partition, and if something
goes wrong, well, cry.
Example : -> the fs crash, and you lose all the data in the partition
(and backup, as murphy law edicts, wasn't working this day)
Did you prefer to lose just /usr, which are easily recreated, or /etc,
/boot (can't boot withtout it ), /usr, /var and so on ?

Other example : due to unforseen evenement, you must add 4 Go to /usr or /var.
did you want to take the risk to do an "resize2fs" on the root
partition and an modification of physical partition, or just lvextend
and resize2fs on a non root partition?

In all corporations I work, there was never a "big /". And this for
linux, aix, solaris or hp-ux.

>> the "good way" of doing this sort of choice in an , is to use a PREFIX
>> variable with configure and let the user change it if they want.
>> In this way, if the user want to create an user "zfs" which wil manage
>> all binaries and lib of zfs in it's home: it's easy and possible.
>>
>> And nobody to say "my way of doing things is better than yours".
>
> Perhaps people who believe in micro-management on this level can also roll
> their own package with their own specific patches for their own custom LFS
> build?
I don't have any problem with the stance "You want it ? You code it!".
Well it's free software after all.
What i don't understand, it's when someone say "justify it. justify
it. It's a nonsense. Justify it. It's a nonsense".


>> I don't even understand why some must justify multiples times
>> 1°) best practice (this is a best practice! Just take any true (plain
>> old?) linux installer, and you will see a choice like  "server  : /,
>> /usr, /home, /var, /tmp are separated).
>
> I think it's time to move from 1980s to the 21st century.
Thanks for the advice. I think that if i'm on this ml , is because i
love eighty ;)

> This was relevant
> when disks were small and expensive. RHEL6 has dropped support for custom
> partitioning in text installers - you have to run the GUI installer to do
> custom, manual partitioning. The only way to do it without the GUI is to
> kickstart it. Don't know about other distros, but I'd be amazed if any
> desktop distro released in the last decade defaults to a separate /usr.
>
Does linux works only on desktop ?

And the fact that isn't on "text install but on gui" doesn't seem
relevant to me.
Any server now can use a gui, and it's been some times we don't do
console install (or in specific hardware).


>> 2°) they're way of manage their systems.
>
> If it's your way to manage the system, you can build your own packages for
> your way of managing the system.
>
> And "that's how I do things" doesn't equal "this is the best way to do it".
>
> Gordan
>



More information about the zfs-discuss mailing list