/ /home on different partitions? - Suse

This is a discussion on / /home on different partitions? - Suse ; On 26 May 2008, in the Usenet newsgroup alt.os.linux.suse, in article , Tobias Crefeld wrote: >> Actually it does. You want to be able to wipe the operating system >> while leaving all the user stuff alone. Ie, /usr/local, /home ...

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3
Results 41 to 55 of 55

Thread: / /home on different partitions?

  1. Re: / /home on different partitions?

    On 26 May 2008, in the Usenet newsgroup alt.os.linux.suse, in article
    , Tobias Crefeld wrote:

    >> Actually it does. You want to be able to wipe the operating system
    >> while leaving all the user stuff alone. Ie, /usr/local, /home should
    >> be on different partitions from the rest. That way wehn you want to
    >> upgrade you can wipe the system and install fresh without having to
    >> worry about /home stuff or programs in /usr/local

    >
    >I never saw a installation routine that changed something on /home nor
    >affected /usr/local . Did you?


    So none of the installs you've done start by _offering_ to partition
    (which you can ignore) and then making a new file system on those
    partitions you've designated? When you make a new file system, anything
    on "this" partition is gone, and that includes /usr/local/, /home/,
    and anything else physically on the partition.

    >There are some advantages in separating /home if you want to put it on
    >a transportable disk but as long as you're using the same disk for a
    >/home- partition I see no advantage.


    Assuming a stand-alone system (where /home/$USER is actually on a local
    disk rather than a network file system) the main advantage is when you
    update to a new version.

    >If you plan to upgrade your system by "wiping" your partitions you will
    >have some more problems because you will loose data under /var oder /svr


    /var/account : Process accounting logs (optional)
    /var/cache : Application cache data
    /var/crash : System crash dumps (optional)
    /var/games : Variable game data (optional)
    /var/lib : Variable state information
    /var/lock : Lock files
    /var/log : Log files and directories
    /var/mail : User mailbox files (optional)
    /var/opt : Variable data for /opt
    /var/run : Run-time variable data
    /var/spool : Application spool data
    /var/tmp : Temporary files preserved between system reboots
    /var/yp : Network Information Service (NIS) database files (optional)

    /var/spool/cron : cron and at jobs

    /srv : Data for services provided by this system

    Obviously a lot is going to depend on what your system is doing, but I'd
    only be concerned with /var/log, /var/mail, and possibly /var/spool. But
    only /var/mail _might_ be critical if Joe User isn't reading his mail, or
    insists on leaving his mail in the spool.

    >as well as configuration data under /etc.


    /etc : Host-specific system configuration

    Generally, the only thing important or unique there are the authentication
    files (/etc/passwd, /etc/group, and the shadow equivalents).

    >This kind of wiping-upgrade is not very effective. We should leave it
    >to MS-Win-(l)users.


    We've been doing so since before Linux was created. It simplifies the
    installation tremenndously, and avoids left-over cruft from N versions
    ago. And that includes /usr/local/ because the compiled stuff that may
    be there is going to have to be recompiled for the "new" libraries and
    similar crap. Updates in place will often run into version
    incompatibilities and/or dependencies. Learned that the hard way when we
    tried updating Red Hat 2.0 to Red Hat 3.0.3 in 1996 on a limited number
    of systems. We wasted a week trying to clean up the mess, before just
    wiping and installing from scratch.

    Old guy

  2. Re: / /home on different partitions?

    houghi wrote:

    ....
    > My preferece would be /share under wich you can then place directories
    > as you see fit, mount it as you see fit, if so desired, give rights as
    > you see fit and so on.


    You braking your head with something that has many optional ways to be
    solved in *nix.

    You 'share' must be accessed over network.
    How many methods you have to do that? NFS, Samba, ftp, http....
    Which one should be used by default, to be accessible to any computer and
    any operating system?

    Than, if every computer exports the same name on the net how to make the
    difference. Prepend computer name? Isn't easier in order to find some
    directory that is exported to have different name that we can read, not
    some PC1234xyz/share and piles of that kind. I change default names on any
    machine in order to get something that I can read.

    Than in Linux you have option that users can login in one machine and do
    their work, but then name doesn't matter anyway, you can set proper
    permissions on any directory.

    The idea with /home/share here is to have them separated from the rest of
    the system, basically the same idea that is behind separate /home.

    --
    Regards, Rajko
    http://en.opensuse.org/Portal needs helpful hands.

  3. Re: / /home on different partitions?

    Rajko M. wrote:
    > ...
    >> My preferece would be /share under wich you can then place directories
    >> as you see fit, mount it as you see fit, if so desired, give rights as
    >> you see fit and so on.

    >
    > You braking your head with something that has many optional ways to be
    > solved in *nix.


    And because there are so many ways, a standard would be nice.

    > You 'share' must be accessed over network.
    > How many methods you have to do that? NFS, Samba, ftp, http....
    > Which one should be used by default, to be accessible to any computer and
    > any operating system?


    Imagine a time where there was no /home and I would propose /home as a
    standard to place directories for the users. Then you could ask yourself
    the same questions.

    However this is completely irrelevant. I am talking about the tree
    structure.

    > Than, if every computer exports the same name on the net how to make the
    > difference. Prepend computer name?


    Huh? Each and every computer has /home and there is no problem there.
    There are other directories that are standard and yet do not pose a
    problem.

    > Isn't easier in order to find some
    > directory that is exported to have different name that we can read, not
    > some PC1234xyz/share and piles of that kind.


    Again, look at the /home directory. Naming is done on the client, the PC
    where you want to see that directory. What you call that is completely
    up to your imagination.

    I would think it would also be unwise to place all files in /share (or
    whereever the default may be). I would place directories in it.

    > I change default names on any
    > machine in order to get something that I can read.


    Nice of you. It has nothing to do with the situation at hand. I am
    talking about a place in the directorystructure.

    > Than in Linux you have option that users can login in one machine and do
    > their work, but then name doesn't matter anyway, you can set proper
    > permissions on any directory.


    I know it is possible.

    > The idea with /home/share here is to have them separated from the rest of
    > the system, basically the same idea that is behind separate /home.


    Indeed. And to be able to (not force to) make it easier to seperate it,
    a top level directory would be a bit more logical. The fact that it will
    be /home/share or /share does not matter in the end on a technical level
    If it will become /home/share I am happy as well, because then at least
    there is a standard.


    houghi
    --
    They say pesticides have been linked to low sperm counts.
    In my opinion if you have bugs down there that are so bad
    you need to use a pesticide, you're not gonna get laid anyway.

  4. Re: / /home on different partitions?

    houghi wrote:
    > And because there are so many ways, a standard would be nice.


    To everybody:

    Let me put it in another way:
    Imagine you work in a company and there are 10 people who need access to
    data on your Linux based infrastructure.
    You already share /home and /opt and /usr and any other directory that
    makes it possible to share.

    The situation is that you have 3 people, Alice, Bob and Charlie, who are
    working on a project. The obviously need to share the data. You know
    that one of those three will only work during the first three months of
    the project, but then will be released. You do not know who this will
    be. The name of the project is ProjectA

    So where would you place the data for them to share?

    Now you have also a ProjectB, ProjectC, ProjectD, ...

    Where would you place that?

    houghi
    --
    They say pesticides have been linked to low sperm counts.
    In my opinion if you have bugs down there that are so bad
    you need to use a pesticide, you're not gonna get laid anyway.

  5. Re: / /home on different partitions?

    Moe Trin meinte:

    > So none of the installs you've done start by _offering_ to partition
    > (which you can ignore) and then making a new file system on those
    > partitions you've designated? When you make a new file system, anything
    > on "this" partition is gone, and that includes /usr/local/, /home/,
    > and anything else physically on the partition.


    I decided very early to install ext3 instead of SUSEs long-term default
    reiserfs and so the last time I created the root-fs on my desktop system
    was after buying the computer 5 years ago (V7.3 ?).


    >> There are some advantages in separating /home if you want to put it on
    >> a transportable disk but as long as you're using the same disk for a
    >> /home- partition I see no advantage.


    > Assuming a stand-alone system (where /home/$USER is actually on a local
    > disk rather than a network file system) the main advantage is when you
    > update to a new version.


    Well, I can only speak for me and cannot say which is the "main" advantage
    for everyone. Maybe you can.
    Wasting disk space just for the rare times you want to destroy file system
    because of upgrades doesn't seem very effective for me as there exists a
    backup of my users data.


    > /etc : Host-specific system configuration


    > Generally, the only thing important or unique there are the
    > authentication files (/etc/passwd, /etc/group, and the shadow
    > equivalents).


    On most of my systems there exist "some" more configuration data which
    took me sometimes days to configure.
    It might be a nice idea for people having enough time to repeat
    installation procedures just because of a OS upgrade in order to keep
    things "clean" but unfortunately I haven't got so much time left and so I
    avoid it.


    >> This kind of wiping-upgrade is not very effective. We should leave it
    >> to MS-Win-(l)users.


    > We've been doing so since before Linux was created. It simplifies the
    > installation tremenndously, and avoids left-over cruft from N versions
    > ago. And that includes /usr/local/ because the compiled stuff that may
    > be there is going to have to be recompiled for the "new" libraries and
    > similar crap. Updates in place will often run into version
    > incompatibilities and/or dependencies. Learned that the hard way when we
    > tried updating Red Hat 2.0 to Red Hat 3.0.3 in 1996 on a limited number
    > of systems. We wasted a week trying to clean up the mess, before just
    > wiping and installing from scratch.


    Maybe things got better? My first production system was based on RH 5.2
    and I never upgraded the distribution - just some applications and the
    kernel - so I can't say what happened in ancient times.

    Last week I downgraded an laptop with oS 10.3 to 10.2 for some tests
    (hardware problem) and afterwards upgraded back to 10.3. No serious
    problems beside the fact that 10.2's kernel doesn't support everything
    that 10.3 does - somehow obvious to understand. Only some applications
    from packman's repo produced conflicts.


    --
    Gruss,
    Tobias.


  6. Re: / /home on different partitions?

    Vahis meinte:
    > On 2008-05-25, houghi wrote:
    >> Vahis wrote:



    > IMHO there are many more standards missing in Linux hierarchy.
    > The configuration files being the worst to me personally, but YMMV.


    >>> Shared only on this computer or also network?
    >>> If network, NFS, Samba or what?


    >> That is irrelevant as to what the standard directory will be.


    > I think not. If all shared files are in one place it causes more work to
    > share different stuff in different ways among different users.


    > I keep different data shared in different ways in different locations,
    > but again, YMMV.


    If we're talking about file services I see no significant advantage for a
    standardized "shared path". On most networks I saw a separate tree for
    these needs, mounted in a directory often simply named like the company.
    Easy to mount local, easy to mount via network and mounted with all
    special needs like ACL, quota, etc. you might have.


    >> All the rest also has nothing to do as to wether you have a standard
    >> or not. Take /home for example. That can be NFS, Samba and what not,
    >> yet /home is the standard place.
    >> /usr is another that can be placed anywhere and can even be ro.
    >>
    >> Everything has a standard place in the hierarchy.


    No, only the files concerning OS or applications need a standardized path.
    Shared user data should be organized in a way that reflects the company's
    / organization's internal structure.


    > Very often I see that SUSE file hierarchy is different than others.
    > Like when configuring Apache. Many files are not in a standard
    > place. RTF Apache M is PITA when each and every file takes long times to
    > find.
    > IMHO widely used packages, de facto applications like Apache servers,
    > _should_ be standard in this sense. But they're not.


    Generally you're right that differences between distributions make things
    complicated without any bigger advantages but apache is a special case.
    Nearly every OS has got its own "apache-FHS". It would be up to the apache
    developers to decide for one. Instead there exists a webpage at apache.org
    with a list of all possible places for Default-DocumentRoot, etc....

    BTW: In practice it's often enough to set some symlinks if you move an
    apache-installation to another OS.

    --
    Gruss,
    Tobias.


  7. Re: / /home on different partitions?

    houghi wrote:

    > houghi wrote:
    >> And because there are so many ways, a standard would be nice.

    >
    > To everybody:
    >
    > Let me put it in another way:
    > Imagine you work in a company and there are 10 people who need access to
    > data on your Linux based infrastructure.
    > You already share /home and /opt and /usr and any other directory that
    > makes it possible to share.
    >
    > The situation is that you have 3 people, Alice, Bob and Charlie, who are
    > working on a project. The obviously need to share the data. You know
    > that one of those three will only work during the first three months of
    > the project, but then will be released. You do not know who this will
    > be. The name of the project is ProjectA
    >
    > So where would you place the data for them to share?
    >
    > Now you have also a ProjectB, ProjectC, ProjectD, ...
    >
    > Where would you place that?
    >
    > houghi


    This way it sounds better.

    Files will be on a file server exported as NFS or Samba share.
    That way project does not depend on any member presence.

    And now I can see what you mean. Where to put project data?
    There is no one standard directory for shared data of all users.
    I guess it is your turn to propose to create /share to FHS.

    --
    Regards, Rajko
    http://en.opensuse.org/Portal needs helpful hands.

  8. Re: / /home on different partitions?

    On 2008-05-30, houghi wrote:

    > Let me put it in another way:
    > Imagine you work in a company and there are 10 people who need access to
    > data on your Linux based infrastructure.
    > You already share /home and /opt and /usr and any other directory that
    > makes it possible to share.
    >
    > The situation is that you have 3 people, Alice, Bob and Charlie, who are
    > working on a project. The obviously need to share the data. You know
    > that one of those three will only work during the first three months of
    > the project, but then will be released. You do not know who this will
    > be. The name of the project is ProjectA



    -- group
    |-- ProjectA
    +-- ProjectB
    | |-- Budget
    | |-- Ref
    | +-- src
    | |-- comm_module_1
    | +-- graphical_interface
    +-- ProjectC...Z


    Something should also be done to enhance group-based ownership over user
    based ownership, for such dirs. A file deposited on those dirs should be
    0wned by the group, not the user. That would avoid a lot of access problems.

    For an OS that's so obviously good as a server, the relation '1 owner and 1
    group to a dir or file' feels weird. And the power of the file owner is too
    great.


    A project-based storage could have project dirs controlled by one or
    multiple groups, and people being members of any number of those groups.

    Imagine 2 groups for ProjectB in the example above:
    ProjectB_mgt (Managment, secretaries, accountants, etc..)
    ProjectB_devel (the developpers)

    ProjectB_mgt could have r/w to the Budget and Ref section, no rights to src.

    ProjectB_devel could have r/o to Ref to read common documents and project
    standards, r/w to Src and no rights to Budget.

    As a member of ProjectA_devel and ProjectB_devel, I would have full access
    to the Src dirs of those projects, be limited to r/o in the Ref dir and not
    even see the Budget dir.


    Because that's another thing missing: if you have access to 3 projects on a
    server that carries 250, why not hide the others? Only Novell Netware had
    that behaviour built-in. I tink we could borrow a few ideas from them.

    Think about it: running a system-wide 'find', would have so much less error
    output if it doesn't even 'see' dirs to which you have no access anyway.


    --
    The sand remembers once there was beach and sunshine
    but chip is warm too
    -- haiku from Effector Online, Volume 1, Number 6

  9. Re: / /home on different partitions?

    On 2008-05-30, Rikishi 42 wrote:
    >
    >
    > On 2008-05-30, houghi wrote:
    >
    >> Let me put it in another way:
    >> Imagine you work in a company and there are 10 people who need access to
    >> data on your Linux based infrastructure.
    >> You already share /home and /opt and /usr and any other directory that
    >> makes it possible to share.
    >>
    >> The situation is that you have 3 people, Alice, Bob and Charlie, who are
    >> working on a project. The obviously need to share the data. You know
    >> that one of those three will only work during the first three months of
    >> the project, but then will be released. You do not know who this will
    >> be. The name of the project is ProjectA

    >
    >
    > -- group


    Perhaps it's better to start in /srv.

    /srv/groups would be a nice little corner to start in ?



    --
    The sand remembers once there was beach and sunshine
    but chip is warm too
    -- haiku from Effector Online, Volume 1, Number 6

  10. shared directories

    Rikishi 42 meinte zu "Re: / /home on different partitions?":

    > -- group
    > |-- ProjectA
    > +-- ProjectB
    > | |-- Budget
    > | |-- Ref
    > | +-- src
    > | |-- comm_module_1
    > | +-- graphical_interface
    > +-- ProjectC...Z


    This is a typical setup in a shared environment no matter whether everyone
    is working on the same host or if they share via NFS, etc..


    > Something should also be done to enhance group-based ownership over user
    > based ownership, for such dirs. A file deposited on those dirs should be
    > 0wned by the group, not the user. That would avoid a lot of access
    > problems.


    It's always owned by user AND group which is not so bad because this way
    you know the creator and have the possibility to use quota..

    Probably you meant that the created file shouldn't get the users primary
    group as GID per default. Fortunately "some" years ago other people had
    the same problem and invented the SGID-bit.
    But of course there will still be the problem that the umask of the
    creator controls the rights of the group concerning the created file and
    this means often only rx for the group.


    > For an OS that's so obviously good as a server, the relation '1 owner
    > and 1 group to a dir or file' feels weird. And the power of the file
    > owner is too great.


    Yes, in file server networks exist often situations where ugo+rwx and just
    one GID per file isn't enough but the good news is: ACL exists!


    > Because that's another thing missing: if you have access to 3 projects
    > on a server that carries 250, why not hide the others? Only Novell
    > Netware had that behaviour built-in. I tink we could borrow a few ideas
    > from them.


    Outside Netwares world with its flags, rights and inherited rights masks
    they call it ACL: man 5 acl

    --
    Gruss,
    Tobias.


  11. Re: / /home on different partitions?

    On 30 May 2008, in the Usenet newsgroup alt.os.linux.suse, in article
    , Tobias Crefeld wrote:

    >Moe Trin meinte:
    >
    >> So none of the installs you've done start by _offering_ to partition
    >> (which you can ignore) and then making a new file system on those
    >> partitions you've designated? When you make a new file system, anything
    >> on "this" partition is gone, and that includes /usr/local/, /home/,
    >> and anything else physically on the partition.

    >
    >I decided very early to install ext3 instead of SUSEs long-term default
    >reiserfs and so the last time I created the root-fs on my desktop system
    >was after buying the computer 5 years ago (V7.3 ?).


    One of the things I've seen over the years is that the amount of stuff
    that gets installed on a _base_ install (never mind the "install all the
    eye-candy" mode) has been increasing consistently. Below, you mention
    Red Hat 5.2 - the box said it needed 120MB min, 450MB workstation, 1.6GB
    server. Looking at a 7.3 box, the minimim diskspace had increased from
    120 Megs to 420 Megs.

    >> Assuming a stand-alone system (where /home/$USER is actually on a local
    >> disk rather than a network file system) the main advantage is when you
    >> update to a new version.


    >Wasting disk space just for the rare times you want to destroy file
    >system because of upgrades doesn't seem very effective for me as
    >there exists a backup of my users data.


    Where is the wasted disk space? In the partition table? Or did you
    partition the disk with the expectation of SuSE 12.4 which will have
    a minimum disk requirement of 1.5 Gigs and a workstation install (with
    all the bells and whistles) over 8.4 Gigs?

    >> Generally, the only thing important or unique there are the
    >> authentication files (/etc/passwd, /etc/group, and the shadow
    >> equivalents).


    >On most of my systems there exist "some" more configuration data which
    >took me sometimes days to configure.


    Yes, I know what you mean. That is why I'm still running FVWM instead of
    the latest windoze wannabe desktops.

    >> Updates in place will often run into version incompatibilities and/or
    >> dependencies. Learned that the hard way when we tried updating Red
    >> Hat 2.0 to Red Hat 3.0.3 in 1996 on a limited number of systems. We
    >> wasted a week trying to clean up the mess, before just wiping and
    >> installing from scratch.

    >
    >Maybe things got better? My first production system was based on RH 5.2
    >and I never upgraded the distribution - just some applications and the
    >kernel - so I can't say what happened in ancient times.


    IF you stayed with the 5.2 errata, that would have been fine, but RH6.0
    improved to an incompatible glibc2 (never mind the fiasco at RH7.0 which
    had a beta version of glibc2 which was virtually incompatible with
    everyone else). The 1996 change was libc4 to libc5, and the executable
    format (remember a.out binaries?) where a major problem. There was a
    similar change in 1997 between RH4.2 and RH5.x which replaced libc5 with
    an early version of glibc2. In both cases, there were compatibility
    libraries, and in both cases the better idea was to replace rather than
    try to upgrade.

    -rw-rw-r-- 1 gferg ldp 24960 May 28 2002 Update
    -rw-rw-r-- 1 gferg ldp 19504 Mar 10 2002 Upgrade

    Yes, they're old mini-howtos - but they do go into more detail.

    Old guy

  12. Re: / /home on different partitions?

    On Sat, 24 May 2008 01:24:29 +0200, houghi wrote:

    >
    > The thing I still miss is where to place shared data. Obviously you can
    > place it anywhere you like, but it would be nice if there were a
    > standard on where to put shared data.
    >


    I have wondered the same thing and over the years looking after Solaris
    and Linux systems have used /data and /space for this sort of thing. Now
    I am starting to think that the fs standard is the way to go. So, without
    there being a standard for group data, I figured that I would use /home
    as it is already automounted.

    To avoid collisions with users, I use uppercase names for the group
    directories, and place symbolic links into the users home directories to
    make it easier to browse using file managers. So user tomw may be a
    member of wanops, so he has a link WANOPS in his $HOME pointing to /home/
    WANOPS. When he opens a file manager he can navigate to WANOPS and see
    the group data. The /home/WANOPS directory has the group sticky bit set
    (chmod g+s) so that all files or directories created within the directory
    inherit the group name (wanops) rather than the users groupname.

    It's not perfect but it is usable.

    Frank Ranner

  13. Re: / /home on different partitions?

    Moe Trin meinte:
    > , Tobias Crefeld wrote:


    >> Wasting disk space just for the rare times you want to destroy file
    >> system because of upgrades doesn't seem very effective for me as
    >> there exists a backup of my users data.


    > Where is the wasted disk space? In the partition table? Or did you
    > partition the disk with the expectation of SuSE 12.4 which will have
    > a minimum disk requirement of 1.5 Gigs and a workstation install (with
    > all the bells and whistles) over 8.4 Gigs?


    What I mean with "wasted": If you divide the disk in partitions you have
    to know in advance how much disk space you will need in which "subtree".
    Of course no one knows how much disk space will be needed in 2 years on
    /home or on /usr or whereever. So you have to provide equal spare place
    for every partition. After some time you recognize that you have used all
    the spare place for one subdirectory. At the other subdirectory you do not
    need the spare place and so this disk space is wasted as it can't get used
    to provide the first partition which runs full.

    --
    Gruss,
    Tobias.


  14. Re: / /home on different partitions?

    Rikishi 42 wrote:
    > Perhaps it's better to start in /srv.
    >
    > /srv/groups would be a nice little corner to start in ?


    /srv is not a standard. Look where people put websited and ftp
    directories. :-(

    houghi
    --
    It's people. Source code is made out of people! They're making our
    source out of people. Next thing they'll be breeding us like cattle
    for code. You've gotta tell them. You've gotta tell them!

  15. Re: / /home on different partitions?

    Frank Ranner wrote:
    > On Sat, 24 May 2008 01:24:29 +0200, houghi wrote:
    >
    >>
    >> The thing I still miss is where to place shared data. Obviously you can
    >> place it anywhere you like, but it would be nice if there were a
    >> standard on where to put shared data.


    > It's not perfect but it is usable.


    Everything that people do now is usable. It just isn't a standard.

    houghi
    --
    It's people. Source code is made out of people! They're making our
    source out of people. Next thing they'll be breeding us like cattle
    for code. You've gotta tell them. You've gotta tell them!

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3