3 ms·

What did CoreOS offer that say ClearLinux, or good ol' Debian do not? It seems like the only difference is you've gottta `packagemanger_xyz install` a couple p

What did CoreOS offer that say ClearLinux, or good ol' Debian do not? It seems like the only difference is you've gottta `packagemanger_xyz install` a couple packages...?

forkexec 7y ago
There was no native userland. You picked an userland and it ran in a container along with /etc and other mounts. The idea being that the OS itself should be separate, developed as a whole and immutable like an appliance OS like FreeNAS, XenServer or VMware ESXi. For ops lifecycle supportability (installs, upgrades, downgrades, etc.), keeping the OS immutable has a lot of advantages in the "system entropy" department because users and admins can't corrupt the OS itself as easily, can replace it more easily and it's far easier for itself to run HIDS against. If it I were developing an immutable OS, there would be a hidden volume containing signed squashfs volumes and updates would be delta overlays that could be merged when the older base volume is no longer needed. Another interesting Linux distro that uses virtualization rather merely containers to isolate system components for security is Qubes OS. Really, I think any new Linux distros should: 1. be developed as an immutable whole 2. run most system and user-added services in containers 3. have package collections like nix or habitat that don't have dependency hells 4. make service and configuration management easy 5. not reinvent the wheel without specific goals and niche/s to occupy that are better than what came before 6. do damn good jobs of smoothing package rough edges, upstreaming patches and rapidly releasing security fixes (including ksplice/kpatch) 7. least surprise everywhere 8. think carefully about whether to go systemd or s6/runit/daemontools 9. manage logs better, preferably without local text files, streamed across a distributed system that scales like flume or kafka
dharmab 7y ago
My team at a Very Large Software Company runs CoreOS for two main reasons: 1. Reduced attack surface due to a very slim OS with no package manager. 2. CoreOS Ignition, a killer app OS provisioning/customization tool. No weird barely-documented kickstart scripts, and no long build and upload times for OS images. We can make changes/customizations to our OS and have them deployed in a cloud within literally minutes. We consider this a competitive advantage.
- m4rtink 7y ago
  I think kickstart is quite well documented, both upstream and in RHEL: https://pykickstart.readthedocs.io/en/latest/https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/installation_guide/sect-kickstart-syntax https://pykickstart.readthedocs.io/en/latest/https://access.... Any concrete examples of stuff the existing docs do not cover ?
  - dharmab 7y ago
    I've maintained both kickstart and ignition professionally. The documentation and readability of Ignition is absolutely way better than kickstart. A simple example would be downloading a binary file and checking it's hash during boot, with retries if the connection is flaky. Three lines of declarative state in Ignition vs complex scripting in kickstart.
    - m4rtink 7y ago
      Ideally one uses mainly kickstart commands to configure the system during the installation - then the installer (Anaconda) takes care for everything for you. If you use custom scripts with kickstart, you are pretty much on your own, like with any other custom script. BTW, maybe open an RFE to include a helper script in the installation environment for easy & robust file downloading ?

What did CoreOS offer that say ClearLinux, or good ol' Debian do not? It seems like the only difference is you've gottta `packagemanger_xyz install` a couple packages...?

forkexec 7y ago

There was no native userland. You picked an userland and it ran in a container along with /etc and other mounts. The idea being that the OS itself should be separate, developed as a whole and immutable like an appliance OS like FreeNAS, XenServer or VMware ESXi. For ops lifecycle supportability (installs, upgrades, downgrades, etc.), keeping the OS immutable has a lot of advantages in the "system entropy" department because users and admins can't corrupt the OS itself as easily, can replace it more easily and it's far easier for itself to run HIDS against. If it I were developing an immutable OS, there would be a hidden volume containing signed squashfs volumes and updates would be delta overlays that could be merged when the older base volume is no longer needed. Another interesting Linux distro that uses virtualization rather merely containers to isolate system components for security is Qubes OS. Really, I think any new Linux distros should: 1. be developed as an immutable whole 2. run most system and user-added services in containers 3. have package collections like nix or habitat that don't have dependency hells 4. make service and configuration management easy 5. not reinvent the wheel without specific goals and niche/s to occupy that are better than what came before 6. do damn good jobs of smoothing package rough edges, upstreaming patches and rapidly releasing security fixes (including ksplice/kpatch) 7. least surprise everywhere 8. think carefully about whether to go systemd or s6/runit/daemontools 9. manage logs better, preferably without local text files, streamed across a distributed system that scales like flume or kafka

dharmab 7y ago

My team at a Very Large Software Company runs CoreOS for two main reasons: 1. Reduced attack surface due to a very slim OS with no package manager. 2. CoreOS Ignition, a killer app OS provisioning/customization tool. No weird barely-documented kickstart scripts, and no long build and upload times for OS images. We can make changes/customizations to our OS and have them deployed in a cloud within literally minutes. We consider this a competitive advantage.

m4rtink 7y ago
I think kickstart is quite well documented, both upstream and in RHEL: https://pykickstart.readthedocs.io/en/latest/https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/installation_guide/sect-kickstart-syntax https://pykickstart.readthedocs.io/en/latest/https://access.... Any concrete examples of stuff the existing docs do not cover ?
- dharmab 7y ago
  I've maintained both kickstart and ignition professionally. The documentation and readability of Ignition is absolutely way better than kickstart. A simple example would be downloading a binary file and checking it's hash during boot, with retries if the connection is flaky. Three lines of declarative state in Ignition vs complex scripting in kickstart.
  - m4rtink 7y ago
    Ideally one uses mainly kickstart commands to configure the system during the installation - then the installer (Anaconda) takes care for everything for you. If you use custom scripts with kickstart, you are pretty much on your own, like with any other custom script. BTW, maybe open an RFE to include a helper script in the installation environment for easy & robust file downloading ?