8 ms·

Having written horrible Debian scripts for open source software that involved setting up postgres, a java package, some python websites with apache and seeing t

Having written horrible Debian scripts for open source software that involved setting up postgres, a java package, some python websites with apache and seeing the mess I made even with the best intentions [0] I think the article is too harsh. Whenever anyone contributes to open source our reaction should be based on love, not hate, even if they mess up. They will eventually fix it up as opposed to deciding not venturing into unknown territory anymore. [0] https://github.com/GeoNode/geonode/blob/master/package/debian/rules https://github.com/GeoNode/geonode/blob/master/package/debia... (Edited to fix typo and formatting)

OnlyRepliesToBS 8y ago
If negative article, ensure proper PR counter above the fold.
grumpydba 8y ago
Sorry but one can never be too harsh when reading "rm /bin/sh" in a shell script.
- Someone1234 8y ago
  Edit: Just nevermind. I don't want to be the target of this hate train.
  - _jal 8y ago
    Uh, I find unrelated software messing with my shell potentially catastrophic. We absolutely blacklist software pulling crap like this - it is a loud, blinking demonstration that the packager is incompetent and will do other, potentially less obvious dangerous things out of ignorance or impatience. Or is there a darker explanation? Untrustworthy, in either case.
  - pjc50 8y ago
    It's not a requirement for /bin/sh to point to bash, only that it be a POSIX shell. The user might have chosen "dash" instead, and the one guy out there who doesn't have "bash" installed might find his system no longer boots.
    - jwilk 8y ago
      In Debian, bash is an essential package. You can assume it's always installed.
      - teknopaul 8y ago
        You can make assumptions like that if the consequences are not serious. In this case boot fails next time if your assumption is wrong.
        tankenmate 8y ago
        https://xkcd.com/1132/ https://xkcd.com/1132/
        dredmorbius 8y ago
        "Essential" is not some arbitrary assumption, but a term of art specific to Debian Policy, and a flag applied to specific packages: Essential is defined as the minimal set of functionality that must be available and usable on the system at all times, even when packages are in the “Unpacked” state. Packages are tagged essential for a system using the Essential control field. The format of the Essential control field is described in Essential. https://www.debian.org/doc/debian-policy/#essential-packages https://www.debian.org/doc/debian-policy/#essential-packages Diversions are addressed in 3.9: https://www.debian.org/doc/debian-policy/#maintainer-scripts https://www.debian.org/doc/debian-policy/#maintainer-scripts Debian Policy, generally, tells package maintainers, not users, what they may or may not do. Several classes of conflict are listed in the document; Microsoft's scrips violate multiple requirements. The goal and result of this ststem, arrived at over 21 years collaborative development (Policy was first published in August 1996) is a system which provides well over 60,000 packages and behaves surprisingly robustly from the user-administrator's perspective. Which is to say, there are few surprises. Microsoft have violated multiple Policy requirements. This is considered a release-critical bug in distro packages for very good reasons.
      - dozzie 8y ago
        OK, fine, then don't add it to the Depends field. But don't replace randomly things with a symlink to bash just because it's installed. If the scripts fail because /bin/sh is not bash, update your fsckin' broken shee-bang line.
  - JdeBP 8y ago
    Aside from the fact that it leaves a window where there is no /bin/sh on the system, because it is not using atomic replacement, that is not what the script is doing. This is a Debian package. /bin/sh has been the Debian Almquist shell for almost three quarters of a decade at this point. * https://lists.debian.org/debian-release/2007/07/msg00027.html https://lists.debian.org/debian-release/2007/07/msg00027.htm... * https://wiki.debian.org/BootProcessSpeedup#Using_a_faster_system_shell https://wiki.debian.org/BootProcessSpeedup#Using_a_faster_sy... * https://wiki.debian.org/DashAsBinSh https://wiki.debian.org/DashAsBinSh * https://wiki.ubuntu.com/DashAsBinSh https://wiki.ubuntu.com/DashAsBinSh * https://wiki.ubuntu.com/DashAsBinSh/Spec https://wiki.ubuntu.com/DashAsBinSh/Spec
  - deleted 8y ago
    [deleted]
- rkangel 8y ago
  Was there ever a stage in your development where you might have done something like that? This is a rhetorical question because we were all there at some point - even if it was age 8 with a first computer. If people are displaying good intentions, and not wildly ignoring a load of clear instructions, then engaging with them will have a much greater chance of producing an educated, productive member of the community, and the more of those the better.
  - fnordsensei 8y ago
    Agreed in general, but also, your argument rests on likening Microsoft to an eight year old using their first computer. Microsoft surely has the means to hire someone who is not an eight year old using their computer for the first time.
    - rkangel 8y ago
      Microsoft is a very big company, with everything from interns and developers only with Windows experience through to seasoned nix developers. This error is actually a good thing from point of view - it's an anecdatum that the whole* company is engaging with open source, not just the bits that know it well. This is something we should encourage and educate. The advantage of educating someone at Microsoft as that their institutional knowledge will persist some fraction of it, so that the next person that comes along is less likely to have issues.
      - seba_dos1 8y ago
        Two words: code review.
      - grawprog 8y ago
        ....they have rm /bin/sh in an install script.... Only way it coulda been worse was something like. rm -f /usr Like...they remove sh..... That's not just some silly little error...
    - msl09 8y ago
      Also it's not just a silly commit that was made on github but an actual software release. Any other software developer would be (and have been) mocked just as hard.
- amyjess 8y ago
  On a related note, I saw this piece of code in a vendor's install script. Not a Debian package, but an executable install script. One of the environment variables has been censored to anonymize the vendor, but everything else is verbatim. # Delete & recreate directory <BLAH>/Patches/<patchLevel>/ # This will confirm write access to BLAH_HOME rm -rf $BLAH_HOME/Patches/${PATCH_VERSION}_${PATCH_LEVEL} mkdir -p $BLAH_HOME/Patches/${PATCH_VERSION}_${PATCH_LEVEL} This is horryfing. No checking the contents of the environment variables. No checking the return codes. WTF. (and IIRC if you google the snippet, you can find where a coworker of mine posted it to Reddit to lampoon it)
- crististm 8y ago
  Reminder for myself: the right level to respond is the minimum level which will trigger a correction. https://www.youtube.com/watch?v=OkebMyDvmxs https://www.youtube.com/watch?v=OkebMyDvmxs Search also Jordan Peterson on how to tickle a baby.
kakwa_ 8y ago
If I publish accidentally a package with rm -rf / in the post installation script, a number of people will angry at me and frankly, I would understand them. That being said, aside from distribution packages, always look at the pre/post (un)install scripts for external packages. rpm -qp --scripts <PACKAGE>.rpm dpkg is a little less convenient but: ls control.tar.* # <<< check that no file like that already exists ar -vx <PACKAGE>.deb tar -xvf control.tar.* for i in pre* post;do printf "\n>>> %s\n" "$i";cat $i;done rm -f conffiles control control.tar. data.tar.* debian-binary md5sums postinst postrm prerm postrm In most cases if the script is huge, the packaging tends to be horrible and generally, the quality of the software is also not that great. Another good indicator is the installation path: dpkg -c <PACKAGE>.deb rpm -qpl <PACKAGE>.rpm If there is no effort made by the editor to follow the FHS or at least be nice and put its messy bundle inside /opt/<COMPAGNY>, it's generally a bad sign. Proprietary software tends to be quite horrible in that regard, I'm still traumatized by the trendmicro serverprotect rpm (AV for linux). http://downloadcenter.trendmicro.com/index.php?regs=NABU&clk=latest&clkval=111&lang_loc=1 http://downloadcenter.trendmicro.com/index.php?regs=NABU&clk... (if you want to give it a try, don't forget the service pack and the product patch...)
- hexxington 8y ago
  `dpkg -I foo.deb` tells you which control components are in a package. If it has a postinst, `dpkg -I foo.deb postinst` will show it to you.
kakwa_ 8y ago
It's not as bad, but the script used to build deb package for azure-cli is a bit weird and not really a thing of beauty: https://github.com/Azure/azure-cli/blob/dev/build_scripts/debian/build.sh https://github.com/Azure/azure-cli/blob/dev/build_scripts/de...
bureado 8y ago
They will eventually fix it up as opposed to... The team released a new package a few hours ago after talking to not only others at MSFT working with Debian and Linux but especially norbusan (OP): https://aka.ms/Oxbegy https://aka.ms/Oxbegy I personally spent just a few hours of the last day with the team but I think our packaging practices are coming out stronger from this. At the very least I think this team is approaching debconf and dpkg-divert and update-alternatives (and the portions of those concepts that can translate to RPM) in a much more thoughtful way. I'm sure that was also what OP intended. (Disclaimer: MSFT employee, just in case.)

OnlyRepliesToBS 8y ago

If negative article, ensure proper PR counter above the fold.

grumpydba 8y ago

Sorry but one can never be too harsh when reading "rm /bin/sh" in a shell script.

Someone1234 8y ago
Edit: Just nevermind. I don't want to be the target of this hate train.
- _jal 8y ago
  Uh, I find unrelated software messing with my shell potentially catastrophic. We absolutely blacklist software pulling crap like this - it is a loud, blinking demonstration that the packager is incompetent and will do other, potentially less obvious dangerous things out of ignorance or impatience. Or is there a darker explanation? Untrustworthy, in either case.
- pjc50 8y ago
  It's not a requirement for /bin/sh to point to bash, only that it be a POSIX shell. The user might have chosen "dash" instead, and the one guy out there who doesn't have "bash" installed might find his system no longer boots.
  - jwilk 8y ago
    In Debian, bash is an essential package. You can assume it's always installed.
    - teknopaul 8y ago
      You can make assumptions like that if the consequences are not serious. In this case boot fails next time if your assumption is wrong.
      - tankenmate 8y ago
        https://xkcd.com/1132/ https://xkcd.com/1132/
      - dredmorbius 8y ago
        "Essential" is not some arbitrary assumption, but a term of art specific to Debian Policy, and a flag applied to specific packages: Essential is defined as the minimal set of functionality that must be available and usable on the system at all times, even when packages are in the “Unpacked” state. Packages are tagged essential for a system using the Essential control field. The format of the Essential control field is described in Essential. https://www.debian.org/doc/debian-policy/#essential-packages https://www.debian.org/doc/debian-policy/#essential-packages Diversions are addressed in 3.9: https://www.debian.org/doc/debian-policy/#maintainer-scripts https://www.debian.org/doc/debian-policy/#maintainer-scripts Debian Policy, generally, tells package maintainers, not users, what they may or may not do. Several classes of conflict are listed in the document; Microsoft's scrips violate multiple requirements. The goal and result of this ststem, arrived at over 21 years collaborative development (Policy was first published in August 1996) is a system which provides well over 60,000 packages and behaves surprisingly robustly from the user-administrator's perspective. Which is to say, there are few surprises. Microsoft have violated multiple Policy requirements. This is considered a release-critical bug in distro packages for very good reasons.
    - dozzie 8y ago
      OK, fine, then don't add it to the Depends field. But don't replace randomly things with a symlink to bash just because it's installed. If the scripts fail because /bin/sh is not bash, update your fsckin' broken shee-bang line.
- JdeBP 8y ago
  Aside from the fact that it leaves a window where there is no /bin/sh on the system, because it is not using atomic replacement, that is not what the script is doing. This is a Debian package. /bin/sh has been the Debian Almquist shell for almost three quarters of a decade at this point. * https://lists.debian.org/debian-release/2007/07/msg00027.html https://lists.debian.org/debian-release/2007/07/msg00027.htm... * https://wiki.debian.org/BootProcessSpeedup#Using_a_faster_system_shell https://wiki.debian.org/BootProcessSpeedup#Using_a_faster_sy... * https://wiki.debian.org/DashAsBinSh https://wiki.debian.org/DashAsBinSh * https://wiki.ubuntu.com/DashAsBinSh https://wiki.ubuntu.com/DashAsBinSh * https://wiki.ubuntu.com/DashAsBinSh/Spec https://wiki.ubuntu.com/DashAsBinSh/Spec
- deleted 8y ago
  [deleted]
rkangel 8y ago
Was there ever a stage in your development where you might have done something like that? This is a rhetorical question because we were all there at some point - even if it was age 8 with a first computer. If people are displaying good intentions, and not wildly ignoring a load of clear instructions, then engaging with them will have a much greater chance of producing an educated, productive member of the community, and the more of those the better.
- fnordsensei 8y ago
  Agreed in general, but also, your argument rests on likening Microsoft to an eight year old using their first computer. Microsoft surely has the means to hire someone who is not an eight year old using their computer for the first time.
  - rkangel 8y ago
    Microsoft is a very big company, with everything from interns and developers only with Windows experience through to seasoned nix developers. This error is actually a good thing from point of view - it's an anecdatum that the whole* company is engaging with open source, not just the bits that know it well. This is something we should encourage and educate. The advantage of educating someone at Microsoft as that their institutional knowledge will persist some fraction of it, so that the next person that comes along is less likely to have issues.
    - seba_dos1 8y ago
      Two words: code review.
    - grawprog 8y ago
      ....they have rm /bin/sh in an install script.... Only way it coulda been worse was something like. rm -f /usr Like...they remove sh..... That's not just some silly little error...
  - msl09 8y ago
    Also it's not just a silly commit that was made on github but an actual software release. Any other software developer would be (and have been) mocked just as hard.
amyjess 8y ago
On a related note, I saw this piece of code in a vendor's install script. Not a Debian package, but an executable install script. One of the environment variables has been censored to anonymize the vendor, but everything else is verbatim. # Delete & recreate directory <BLAH>/Patches/<patchLevel>/ # This will confirm write access to BLAH_HOME rm -rf $BLAH_HOME/Patches/${PATCH_VERSION}_${PATCH_LEVEL} mkdir -p $BLAH_HOME/Patches/${PATCH_VERSION}_${PATCH_LEVEL} This is horryfing. No checking the contents of the environment variables. No checking the return codes. WTF. (and IIRC if you google the snippet, you can find where a coworker of mine posted it to Reddit to lampoon it)
crististm 8y ago
Reminder for myself: the right level to respond is the minimum level which will trigger a correction. https://www.youtube.com/watch?v=OkebMyDvmxs https://www.youtube.com/watch?v=OkebMyDvmxs Search also Jordan Peterson on how to tickle a baby.

kakwa_ 8y ago

If I publish accidentally a package with rm -rf / in the post installation script, a number of people will angry at me and frankly, I would understand them. That being said, aside from distribution packages, always look at the pre/post (un)install scripts for external packages. rpm -qp --scripts <PACKAGE>.rpm dpkg is a little less convenient but: ls control.tar.* # <<< check that no file like that already exists ar -vx <PACKAGE>.deb tar -xvf control.tar.* for i in pre* post;do printf "\n>>> %s\n" "$i";cat $i;done rm -f conffiles control control.tar. data.tar.* debian-binary md5sums postinst postrm prerm postrm In most cases if the script is huge, the packaging tends to be horrible and generally, the quality of the software is also not that great. Another good indicator is the installation path: dpkg -c <PACKAGE>.deb rpm -qpl <PACKAGE>.rpm If there is no effort made by the editor to follow the FHS or at least be nice and put its messy bundle inside /opt/<COMPAGNY>, it's generally a bad sign. Proprietary software tends to be quite horrible in that regard, I'm still traumatized by the trendmicro serverprotect rpm (AV for linux). http://downloadcenter.trendmicro.com/index.php?regs=NABU&clk=latest&clkval=111&lang_loc=1 http://downloadcenter.trendmicro.com/index.php?regs=NABU&clk... (if you want to give it a try, don't forget the service pack and the product patch...)

hexxington 8y ago
`dpkg -I foo.deb` tells you which control components are in a package. If it has a postinst, `dpkg -I foo.deb postinst` will show it to you.

kakwa_ 8y ago

It's not as bad, but the script used to build deb package for azure-cli is a bit weird and not really a thing of beauty: https://github.com/Azure/azure-cli/blob/dev/build_scripts/debian/build.sh https://github.com/Azure/azure-cli/blob/dev/build_scripts/de...

bureado 8y ago

They will eventually fix it up as opposed to... The team released a new package a few hours ago after talking to not only others at MSFT working with Debian and Linux but especially norbusan (OP): https://aka.ms/Oxbegy https://aka.ms/Oxbegy I personally spent just a few hours of the last day with the team but I think our packaging practices are coming out stronger from this. At the very least I think this team is approaching debconf and dpkg-divert and update-alternatives (and the portions of those concepts that can translate to RPM) in a much more thoughtful way. I'm sure that was also what OP intended. (Disclaimer: MSFT employee, just in case.)