Announcement

Collapse
No announcement yet.

Systemd Change Allows For Stateless Systems With Tmpfs

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by duby229 View Post
    Well, etc-update is a bit more powerful than the blog quote you made. It is possible for users to delete "pristine" settings. I'd bet most users do. For the fact that "pristine" settings aren't meant for deployed systems. As soon as etc is configured properly "pristine" settings don't matter anymore.
    It depends very much on how the program is configured. For Apache or systemd, you leave the pristine settings alone and override only what you need. This is the preferred way of working with configuration management systems like puppet or ansible. If you only override specific directives, it makes it much easier to see what has changed on a system or a cluster of systems. Replacing the configuration files wholesale is trivial but not scalable when you are working with templating.

    Also, there are systems (think kiosks) where every boot has to return it to a pre-configured state. You need init integration for this to work well.

    Comment


    • #22
      I don't get the difference. If it's in /etc or if it's in /usr it's still somewhere.

      Comment


      • #23
        Originally posted by duby229 View Post
        I don't get the difference. If it's in /etc or if it's in /usr it's still somewhere.
        /usr is system supplied. /etc is user overrides. that is the difference.

        Comment


        • #24
          Originally posted by Karl Napf View Post
          usr is short for Unix System Resources
          A bit off topic but I am not sure you are right here.
          AFAIK usr was the short hand for "user" because all the user data was stored in /usr in 1969.
          Later, /home was introduced and /usr was basically resued as a mounting point for a "second" root file system so your commands could go either
          /bin or /usr/bin. Moving up to today, we have no /bin any more but it is all in /usr/bin instead.
          At least if I haven't screwed up my unix history lessons

          Comment


          • #25
            Originally posted by RahulSundaram View Post
            /usr is system supplied. /etc is user overrides. that is the difference.
            That still doesn't make any sense though. Once a file is configured in /etc you'll have a completely redundant and incorrect file in /usr. It still doesn't make any sense.

            EDIT: and if the unmodified config files in /usr aren't mirrored into /etc then you wind up with a situation where config files are strewn all around.

            Comment


            • #26
              Originally posted by duby229 View Post
              That still doesn't make any sense though. Once a file is configured in /etc you'll have a completely redundant and incorrect file in /usr. It still doesn't make any sense.
              I don't know what is so confusing. You have a file in /usr/. You can override specific portions or the entire file in /etc/. Program will read /etc first and /usr next and combine them both if needed to get the entire settings.

              Comment


              • #27
                Originally posted by duby229 View Post
                EDIT: and if the unmodified config files in /usr aren't mirrored into /etc then you wind up with a situation where config files are strewn all around.
                Mirroring the entire file would of course be silly thing to do. You only override what you are actually changing.

                Comment


                • #28
                  Originally posted by RahulSundaram View Post
                  I don't know what is so confusing. You have a file in /usr/. You can override specific portions or the entire file in /etc/. Program will read /etc first and /usr next and combine them both if needed to get the entire settings.
                  It wouldn't take very much complexity to make that completely unreadable and unmaintainable. If it doesn't even require the whole configuration file in /etc it can break context. It wouldn't take much complexity before you'd no idea what the hell you're looking at.

                  Comment


                  • #29
                    Originally posted by duby229 View Post
                    It wouldn't take very much complexity to make that completely unreadable and unmaintainable. If it doesn't even require the whole configuration file in /etc it can break context. It wouldn't take much complexity before you'd no idea what the hell you're looking at.
                    Not really. Changes are pretty trivially recognizable.



                    latest version of systemd even includes wrappers like systemd-cat and systemd-edit to abstract it away as an implementation detail.

                    Comment


                    • #30
                      Originally posted by duby229 View Post
                      It wouldn't take very much complexity to make that completely unreadable and unmaintainable. If it doesn't even require the whole configuration file in /etc it can break context. It wouldn't take much complexity before you'd no idea what the hell you're looking at.
                      This already happens pretty routinely with per-user settings. Defaults are in /usr, if a user changes something then the changes are stored in his or her home directory.

                      Comment

                      Working...
                      X