5 ms·

This is so wrong on so many levels. So many complications. Monstrously huge binaries. Static linking. Docker and Nix mess of complex instructions, all custom. W

This is so wrong on so many levels. So many complications. Monstrously huge binaries. Static linking. Docker and Nix mess of complex instructions, all custom. With RPM, it is one command, rpmbuild, with a standardized spec file and no need to link statically. No Docker image needed, or anything else. Just plug into a yum repository or into a Kickstart install group and you're done. No code or compose files or playbooks to write. Turn the VM on and have it automatically PXE / DHCP / TFTP boot and Kickstart install it with the desired software and configuration. Without writing a single line of code or lifting a finger.

Nullabillity 7y ago
And now your setup depends on working PXE (which requires custom DHCP config!) and a custom RPM registry. How is that less complex operationally? And you need to write custom rpmspecs and kickstart manifests. Do those not count as code? Kickstart also doesn't help you with any day-two ops concerns.
- Annatar 7y ago
  "Custom DHCP config"?!? You do realize DHCP stands for "dynamic host configuration protocol"? That's exactly what it was designed for... And if you can't get "working PXE" (PXE is implemented in firmware, by the way), you might want to brush up on the basics of putting together an IT infrastructure, or this moment might be a good time for a career switch out of IT... There are no "Kickstart manifests", it's a ruleset. There is no "RPM registry" (this isn't Windows™️) or anything of the sort. There are no "custom spec files" as it's a formalized format with grammar and lexicography which the OS's software management subsystem understands - it's like putting a VHS tape into a video cassette recorder, modular and standardized. Day two is where a software deployment server and clearly defined change management process according to the department of defense capability maturity model come into play.
  - Nullabillity 7y ago
    > "Custom DHCP config"?!? You do realize DHCP stands for "dynamic host configuration protocol"? That's exactly what it was designed for... Usually used for assigning network configuration dynamically. I'd venture a guess that most people never touch their DHCP configuration, aside from assigning DNS and IP pools. And good luck getting your hosting provider to give you raw access to their DHCP config. > And if you can't get "working PXE" (PXE is implemented in firmware, by the way), you might want to brush up on the basics of putting together an IT infrastructure, or this moment might be a good time for a career switch out of IT... There is a lot more to stable PXE than having a client. Nevermind the insanity of effectively giving anyone who can broadcast IP packets root access to all new servers. > There are no "Kickstart manifests", it's a ruleset. Different words, same thing. > There is no "RPM registry" (this isn't Windows™️) or anything of the sort. Correct, guess I've done too much Docker recently. Meant RPM repository. Unless you're shipping around your RPMs manually? In which case, I refer back to the day two question marks. > There are no "custom spec files" as it's a formalized format with grammar and lexicography which the OS's software management subsystem understands - it's like putting a VHS tape into a video cassette recorder, modular and standardized. So.. the same as Nix definitions then? Except with Nix you don't have to worry about whether the system was set up for VHS or Betamax. > Day two is where a software deployment server and clearly defined change management process according to the department of defense capability maturity model come into play. So.. completely unrelated to the process you've advocated so far?
    - Annatar 7y ago
      Not unrelated, in tandem. Once the systems are provisioned, the software deployment server is used to mass deploy components and bundles (OS packages) and is integrated into the change management process (for example, no deployment to production without an approved change request identifier).
  - nrr 7y ago
    The PXE client is implemented in firmware, but for the PXE client to have anything to talk to, there's a sizable amount of moving parts to configure just right in order for it to work well. Those moving parts often include telling your dhcpd to include some additional payloads to offer to clients when they obtain IP leases. This is in tandem with getting tftpd running, writing your ks.cfg, and writing a suitable pxelinux.cfg so that you can boot into Anaconda to install the OS. This is all assuming that you even have the appropriate access to do these things in our increasingly cloud-centric world. Amazon, Microsoft, and Google all won't let you use PXE to provision VMs. Notwithstanding, networks that are IPv6-only pose a problem for netboot installations. PXE doesn't work so well there unless you make the conscious decision to use DHCPv6 over stateless autoconfiguration. -- Now, this all said, you're on something resembling the right track with respect to OS packages. There's a common pattern (at least in my experience) in the public cloud world where you use something like Packer to build a machine image for provisioning a VM in, e.g., EC2. I've used Kickstart to great effect here in conjunction with some rules in the build system for autogenerating specfiles to hand off to rpmbuild. Combine that with a set of functional and integration tests (the apps I wrote during this period of my life were in Ruby, so the tests were in Ruby, but the technology doesn't matter; you could just as well use ksh93 or pdksh) to ensure that the image you built is what you expect, and it's actually rather killer. The only things that yum/rpmbuild truly lacks that Nix gives us for free are (1) a package build environment, on Linux at least, that's hermetic all the way down to libc; (2) the ability to install more than one release of a particular library at a time without confusing the dynamic linker machinery; and (3) a way to herald when to rebuild certain packages based on changes to their dependencies. Apropos deployment and running in production, the intent then is to keep it immutable (you disallow SSH as a general rule after day one, right?) and for your change management process to consider the VM as a whole deployment unit. Want to deploy updated configuration? Deploy new VMs. Want to deploy a new software release? Deploy new VMs.
    - Annatar 7y ago
      SSH is not disallowed, because there are still cases where it is necessary to ssh in order to service faulty hardware. However, ssh is disallowed for making any ad hoc changes to any system, unless that is done by removing, installing, or upgrading a configuration OS package. It would be better to say that any commands which manipulate system state by hand are disallowed. In worst case scenario, every system is a throwaway one: since the configuration is 100% OS packaged, I can just re-instantiate a server, be it physical or VM. I don't have AWS or hosting trouble because I didn't fall for external hosting hype, and having everything system engineered, I run everything on-premise for peanuts. AWS or Azure just cannot compete with me in cost.
deleted 7y ago
[deleted]

Nullabillity 7y ago

And now your setup depends on working PXE (which requires custom DHCP config!) and a custom RPM registry. How is that less complex operationally? And you need to write custom rpmspecs and kickstart manifests. Do those not count as code? Kickstart also doesn't help you with any day-two ops concerns.

Annatar 7y ago
"Custom DHCP config"?!? You do realize DHCP stands for "dynamic host configuration protocol"? That's exactly what it was designed for... And if you can't get "working PXE" (PXE is implemented in firmware, by the way), you might want to brush up on the basics of putting together an IT infrastructure, or this moment might be a good time for a career switch out of IT... There are no "Kickstart manifests", it's a ruleset. There is no "RPM registry" (this isn't Windows™️) or anything of the sort. There are no "custom spec files" as it's a formalized format with grammar and lexicography which the OS's software management subsystem understands - it's like putting a VHS tape into a video cassette recorder, modular and standardized. Day two is where a software deployment server and clearly defined change management process according to the department of defense capability maturity model come into play.
- Nullabillity 7y ago
  > "Custom DHCP config"?!? You do realize DHCP stands for "dynamic host configuration protocol"? That's exactly what it was designed for... Usually used for assigning network configuration dynamically. I'd venture a guess that most people never touch their DHCP configuration, aside from assigning DNS and IP pools. And good luck getting your hosting provider to give you raw access to their DHCP config. > And if you can't get "working PXE" (PXE is implemented in firmware, by the way), you might want to brush up on the basics of putting together an IT infrastructure, or this moment might be a good time for a career switch out of IT... There is a lot more to stable PXE than having a client. Nevermind the insanity of effectively giving anyone who can broadcast IP packets root access to all new servers. > There are no "Kickstart manifests", it's a ruleset. Different words, same thing. > There is no "RPM registry" (this isn't Windows™️) or anything of the sort. Correct, guess I've done too much Docker recently. Meant RPM repository. Unless you're shipping around your RPMs manually? In which case, I refer back to the day two question marks. > There are no "custom spec files" as it's a formalized format with grammar and lexicography which the OS's software management subsystem understands - it's like putting a VHS tape into a video cassette recorder, modular and standardized. So.. the same as Nix definitions then? Except with Nix you don't have to worry about whether the system was set up for VHS or Betamax. > Day two is where a software deployment server and clearly defined change management process according to the department of defense capability maturity model come into play. So.. completely unrelated to the process you've advocated so far?
  - Annatar 7y ago
    Not unrelated, in tandem. Once the systems are provisioned, the software deployment server is used to mass deploy components and bundles (OS packages) and is integrated into the change management process (for example, no deployment to production without an approved change request identifier).
- nrr 7y ago
  The PXE client is implemented in firmware, but for the PXE client to have anything to talk to, there's a sizable amount of moving parts to configure just right in order for it to work well. Those moving parts often include telling your dhcpd to include some additional payloads to offer to clients when they obtain IP leases. This is in tandem with getting tftpd running, writing your ks.cfg, and writing a suitable pxelinux.cfg so that you can boot into Anaconda to install the OS. This is all assuming that you even have the appropriate access to do these things in our increasingly cloud-centric world. Amazon, Microsoft, and Google all won't let you use PXE to provision VMs. Notwithstanding, networks that are IPv6-only pose a problem for netboot installations. PXE doesn't work so well there unless you make the conscious decision to use DHCPv6 over stateless autoconfiguration. -- Now, this all said, you're on something resembling the right track with respect to OS packages. There's a common pattern (at least in my experience) in the public cloud world where you use something like Packer to build a machine image for provisioning a VM in, e.g., EC2. I've used Kickstart to great effect here in conjunction with some rules in the build system for autogenerating specfiles to hand off to rpmbuild. Combine that with a set of functional and integration tests (the apps I wrote during this period of my life were in Ruby, so the tests were in Ruby, but the technology doesn't matter; you could just as well use ksh93 or pdksh) to ensure that the image you built is what you expect, and it's actually rather killer. The only things that yum/rpmbuild truly lacks that Nix gives us for free are (1) a package build environment, on Linux at least, that's hermetic all the way down to libc; (2) the ability to install more than one release of a particular library at a time without confusing the dynamic linker machinery; and (3) a way to herald when to rebuild certain packages based on changes to their dependencies. Apropos deployment and running in production, the intent then is to keep it immutable (you disallow SSH as a general rule after day one, right?) and for your change management process to consider the VM as a whole deployment unit. Want to deploy updated configuration? Deploy new VMs. Want to deploy a new software release? Deploy new VMs.
  - Annatar 7y ago
    SSH is not disallowed, because there are still cases where it is necessary to ssh in order to service faulty hardware. However, ssh is disallowed for making any ad hoc changes to any system, unless that is done by removing, installing, or upgrading a configuration OS package. It would be better to say that any commands which manipulate system state by hand are disallowed. In worst case scenario, every system is a throwaway one: since the configuration is 100% OS packaged, I can just re-instantiate a server, be it physical or VM. I don't have AWS or hosting trouble because I didn't fall for external hosting hype, and having everything system engineered, I run everything on-premise for peanuts. AWS or Azure just cannot compete with me in cost.

deleted 7y ago

[deleted]