5 ms·

When I first started packaging software for $employer, we adhered to the FHS. Then we started shipping software to corporate customers, who have Policies and Ru

by elric 4y ago

When I first started packaging software for $employer, we adhered to the FHS. Then we started shipping software to corporate customers, who have Policies and Rules and Expectations which are diametrically opposed to the FHS. They don't want logs in /var/log, nor binaries in /usr/[local]/bin, because then someone with root access has to be involved in the installation process. They don't even want an RPM if they can help it, for the same reason. In the end we revamped the whole shebang and everything lives in our own folder structure whose root can be anywhere, where everything can be owned by arbitrary users, because customers are afraid of root. They don't care that this makes their installation less secure, because they are convinced that it makes things more secure. shrug

IshKebab 4y ago
> because customers are afraid of root You mean because that's obviously way more sane than spewing the installation of every piece of software all over the system. There's a reason it's basically only Unix that works like that. Slightly disappointing that you were directly confronted with the problems of the FHS but still think it's better... because customers are idiots or something.
- bhaak 4y ago
  With a proper package manager that keeps track of the installed files and a proper permission system, it doesn't matter where the files are.
  - Joker_vD 4y ago
    As long as you don't move them around without notifying the proper package manager: which one, by the way? There is dpkg, and apt, and npm, and pip3, and...
    - bhaak 4y ago
      If you install into the root hierarchy then you must use the one that your OS is using. Creating such a package for your application can be a nuisance but it really is not rocket science. You can only use language specific packager managers like npm and pip3 if you install into a specific sub directory outside of OS file hierarchy conventions.
- jkaplowitz 4y ago
  > You mean because that's obviously way more sane than spewing the installation of every piece of software all over the system. > There's a reason it's basically only Unix that works like that. I think you're underestimating how common it is for software on both Windows and macOS (the former more than the latter) to spew its bits all over the system. In the case of Windows especially, this includes things like the Registry and events sent to Event Viewer.
- Macha 4y ago
  As far as I know, iOS is the only OS that is _not_ like this. macOS has /Applications, /Library, their equivalents under the user's home directory, applications that ignore macOS conventions and use XDG ones... Windows has AppData in three variations, Program Files, Documents... Android has /Android/data, apps that stick stuff in /storage/emulated
  - IshKebab 4y ago
    None of those are like what Unix does though. I'm not saying you shouldn't store configuration data in some other location to the app itself. That's quite reasonable. What Unix does is mix up the contents of all the apps themselves. All app binaries are in `/usr/bin`. All libraries are in `/usr/lib`. All their data is in `/usr/share`. No other OS does that as far as I am aware.
    - icedchai 4y ago
      When I built my own packages, back in the old days, I would never adhere to this standard. I found spreading different pieces and parts of the same app all over the filesystem to be a bit bizarre. If I built Apache, it was built with a prefix of /usr/local/apache_VERSION, with a link from /usr/local/apache. This made it easy to upgrade: I'd build a new version (with a new prefix), migrate the configs (if needed), change the symlink (which was really just for each of tracking the current version), then blow away the old version. This was back in the "servers as pets" days.
- elric 4y ago
  Disappointing? Sorry to read I've disappointed you, dear internet user. I've administered a lot of systems over the years, and they often contain tools I don't really know and didn't install. It's always much easier to look for things in the usual places, like logs in /var/log, instead of having to figure out where each random application decided dump its stuff. I'm quite fond of the path of least surprises. Splitting an installation across multiple locations has additional benefits. It's a good thing that the application user can't modify the binaries (which is pretty much enforced when the binaries live in /usr). You can achieve the same thing when dumping everything in /opt/$foo, but that's pretty much the worst of both worlds imo.
  - drpyser22 4y ago
    What do you think about something like Nix/NixOS?
  - mistrial9 4y ago
    not a *nix fan but professional computer science here; my limited understanding was that the Debian people took on their own methods of breaking things up and re-ordering them; there is no *nix standard despite multiple efforts at standards, only de-facto practices; powerful and arrogant people along with hurried and clueless people, repeatedly build setups that do not follow standards, as detailed in the post.
  - IshKebab 4y ago
    > It's a good thing that the application user can't modify the binaries Why?
    - noisem4ker 4y ago
      To prevent damage from malware running with user privileges. If the user really needs to modify the binaries, they can reach out for sudo or ask the sysadmin. It's such a rare and risky use case that it warrants a barrier normally being in place.
      - IshKebab 4y ago
- forgotpwd16 4y ago
  >it's basically only Unix that works like that How are others systems doing it?
  - IshKebab 4y ago
    They keep all of the installation in one place. Config and cache data can be in different places but the program itself is in one place. On Mac this is the app bundle. On Android it's the unzipped APK. I think NixOS does this too but I'm not too familiar with it. Even Windows more or less does this - all the data is in c:/Program Files/The App. Well at least in theory. Windows is pretty messy.
10000truths 4y ago
The XDG specification is more sensible, in my opinion - configurable user-specific directories for things like executables and libraries, with a sane default prefix of "$HOME/.local".
throw0101a 4y ago
Isn't that what /opt/{provider or package}/ is for? * https://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES https://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLIC... * https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#optAddonApplicationSoftwarePackages https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#op...
- deleted 4y ago
  [deleted]
twic 4y ago
I do think that the practices that evolved in early unix, and which are, after a modest amount of evolution, codified in the FHS, are not a good fit to modern systems, where software comes in packages, and you want to be able to deal with packages differently according to whether they come from the system package manager, vendors, internal developers, etc. I wonder if we could have a rework of the classic layout where we have /usr/share, /usr/<arch>/bin, /usr/<arch>/lib, /etc, /var/lib, /var/cache, and /tmp, but then inside those, enforce a rule that everything is in a subdirectory named after its package. So you would have dropped your stuff into /usr/x86-64/bin/elricsapp/elricsapp, /etc/elricsapp/elricsapp.conf, etc. Then the customer sysadmins could have simply created those directory, chown'd them to a new elricsapp user, and installed your software as a normal user. You'd either have an astoundingly long-winded PATH and LIBPATH, or have some procedure for collecting symlinks to everything in /usr/bin.
- icedchai 4y ago
  Just put "elericsapp" in a subdirectory under /opt or /usr/local and keep it simple. Why spread it all over the place?
  - twic 4y ago
    Fair. The only reason to split it up is to make it easier to do things like putting the read-only bits on a read-only filesystem, backing up all the config in one go, etc.
Rapzid 4y ago
Nah, they want rpm so they can rpm lint it. Even if they are deploying containers because their security processes still require rpm. And so you have to make just about everything in the package relocatable. Good fun.

by elric 4y ago

IshKebab 4y ago

> because customers are afraid of root You mean because that's obviously way more sane than spewing the installation of every piece of software all over the system. There's a reason it's basically only Unix that works like that. Slightly disappointing that you were directly confronted with the problems of the FHS but still think it's better... because customers are idiots or something.

bhaak 4y ago
With a proper package manager that keeps track of the installed files and a proper permission system, it doesn't matter where the files are.
- Joker_vD 4y ago
  As long as you don't move them around without notifying the proper package manager: which one, by the way? There is dpkg, and apt, and npm, and pip3, and...
  - bhaak 4y ago
    If you install into the root hierarchy then you must use the one that your OS is using. Creating such a package for your application can be a nuisance but it really is not rocket science. You can only use language specific packager managers like npm and pip3 if you install into a specific sub directory outside of OS file hierarchy conventions.
jkaplowitz 4y ago
> You mean because that's obviously way more sane than spewing the installation of every piece of software all over the system. > There's a reason it's basically only Unix that works like that. I think you're underestimating how common it is for software on both Windows and macOS (the former more than the latter) to spew its bits all over the system. In the case of Windows especially, this includes things like the Registry and events sent to Event Viewer.
Macha 4y ago
As far as I know, iOS is the only OS that is _not_ like this. macOS has /Applications, /Library, their equivalents under the user's home directory, applications that ignore macOS conventions and use XDG ones... Windows has AppData in three variations, Program Files, Documents... Android has /Android/data, apps that stick stuff in /storage/emulated
- IshKebab 4y ago
  None of those are like what Unix does though. I'm not saying you shouldn't store configuration data in some other location to the app itself. That's quite reasonable. What Unix does is mix up the contents of all the apps themselves. All app binaries are in `/usr/bin`. All libraries are in `/usr/lib`. All their data is in `/usr/share`. No other OS does that as far as I am aware.
  - icedchai 4y ago
    When I built my own packages, back in the old days, I would never adhere to this standard. I found spreading different pieces and parts of the same app all over the filesystem to be a bit bizarre. If I built Apache, it was built with a prefix of /usr/local/apache_VERSION, with a link from /usr/local/apache. This made it easy to upgrade: I'd build a new version (with a new prefix), migrate the configs (if needed), change the symlink (which was really just for each of tracking the current version), then blow away the old version. This was back in the "servers as pets" days.
elric 4y ago
Disappointing? Sorry to read I've disappointed you, dear internet user. I've administered a lot of systems over the years, and they often contain tools I don't really know and didn't install. It's always much easier to look for things in the usual places, like logs in /var/log, instead of having to figure out where each random application decided dump its stuff. I'm quite fond of the path of least surprises. Splitting an installation across multiple locations has additional benefits. It's a good thing that the application user can't modify the binaries (which is pretty much enforced when the binaries live in /usr). You can achieve the same thing when dumping everything in /opt/$foo, but that's pretty much the worst of both worlds imo.
- drpyser22 4y ago
  What do you think about something like Nix/NixOS?
- mistrial9 4y ago
  not a *nix fan but professional computer science here; my limited understanding was that the Debian people took on their own methods of breaking things up and re-ordering them; there is no *nix standard despite multiple efforts at standards, only de-facto practices; powerful and arrogant people along with hurried and clueless people, repeatedly build setups that do not follow standards, as detailed in the post.
- IshKebab 4y ago
  > It's a good thing that the application user can't modify the binaries Why?
  - noisem4ker 4y ago
    To prevent damage from malware running with user privileges. If the user really needs to modify the binaries, they can reach out for sudo or ask the sysadmin. It's such a rare and risky use case that it warrants a barrier normally being in place.
    - IshKebab 4y ago
forgotpwd16 4y ago
>it's basically only Unix that works like that How are others systems doing it?
- IshKebab 4y ago
  They keep all of the installation in one place. Config and cache data can be in different places but the program itself is in one place. On Mac this is the app bundle. On Android it's the unzipped APK. I think NixOS does this too but I'm not too familiar with it. Even Windows more or less does this - all the data is in c:/Program Files/The App. Well at least in theory. Windows is pretty messy.

10000truths 4y ago

The XDG specification is more sensible, in my opinion - configurable user-specific directories for things like executables and libraries, with a sane default prefix of "$HOME/.local".

throw0101a 4y ago

Isn't that what /opt/{provider or package}/ is for? * https://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES https://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLIC... * https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#optAddonApplicationSoftwarePackages https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#op...

deleted 4y ago
[deleted]

twic 4y ago

I do think that the practices that evolved in early unix, and which are, after a modest amount of evolution, codified in the FHS, are not a good fit to modern systems, where software comes in packages, and you want to be able to deal with packages differently according to whether they come from the system package manager, vendors, internal developers, etc. I wonder if we could have a rework of the classic layout where we have /usr/share, /usr/<arch>/bin, /usr/<arch>/lib, /etc, /var/lib, /var/cache, and /tmp, but then inside those, enforce a rule that everything is in a subdirectory named after its package. So you would have dropped your stuff into /usr/x86-64/bin/elricsapp/elricsapp, /etc/elricsapp/elricsapp.conf, etc. Then the customer sysadmins could have simply created those directory, chown'd them to a new elricsapp user, and installed your software as a normal user. You'd either have an astoundingly long-winded PATH and LIBPATH, or have some procedure for collecting symlinks to everything in /usr/bin.

icedchai 4y ago
Just put "elericsapp" in a subdirectory under /opt or /usr/local and keep it simple. Why spread it all over the place?
- twic 4y ago
  Fair. The only reason to split it up is to make it easier to do things like putting the read-only bits on a read-only filesystem, backing up all the config in one go, etc.

Rapzid 4y ago

Nah, they want rpm so they can rpm lint it. Even if they are deploying containers because their security processes still require rpm. And so you have to make just about everything in the package relocatable. Good fun.