We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Atomic Updates - and /etc?

00:00

Formal Metadata

Title
Atomic Updates - and /etc?
Subtitle
How to handle updates of config files in /etc
Title of Series
Number of Parts
40
Author
Contributors
License
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
The great thing on atomic updates as used e.g. with transactional-update is, that your system is always in a defined state. But what happens with changes in /etc? With normal updates, changes are done immediately to /etc during the updates. With atomic updates, they are only visible with the next reboot. Which means, changes between update and reboot to /etc can create a conflict. There are several strategies by other distributions, like three-way-diff and patching, symlinks, ignoring the problem, etc. In this talk I will mention the biggest challenges we see, which solutions do exist, what are the advantages and what the disadvantages and which impact this will have on normal distributions like openSUSE Tumbleweed. This talk is to create awareness for the problem and as base for discussions, it will not provide a solution for every problem. It's targeting application developers and distribution developers, as this are the areas were changes would be necessary.
Cubic graphMathematicsProduct (business)Database transactionBitSource codeConfiguration spaceCASE <Informatik>SpacetimeComputer fileInformation systemsKeyboard shortcutFerry CorstenDependent and independent variablesComputer animation
Computer fileConfiguration spaceAtomic numberSystem administratorService (economics)Type theoryPhysical systemFactory (trading post)Mechanism designProbability distributionLocal ringServer (computing)WhiteboardCodeSoftwareTerm (mathematics)Atomic numberNormal distributionSoftwareConfiguration spaceStandard deviationSoftware developerMathematicsComputer fileLevel (video gaming)Information systemsApproximationGroup actionCanonical ensembleAuditory maskingMultiplication signHand fanBootingGoodness of fitPhysical systemInformation securityServer (computing)Service (economics)Length of stayUniformer RaumCASE <Informatik>WebsiteAnalytic continuationRankingMobile appAffine spaceStructural loadGame theoryProduct (business)Musical ensembleOSI modelSpacetimeLipschitz-StetigkeitMoving averageData conversionMetropolitan area networkDirected graphRing (mathematics)Single-board computerSystem callControl systemDatabaseHierarchyBitSeries (mathematics)Factory (trading post)System administratorDatabase transactionUniform resource locatorMonster groupMiniDiscOpen setSet (mathematics)MetreWave packetPoint (geometry)Revision controlSynchronizationDecimalProbability distributionState of matterBlock (periodic table)Message passingType theoryArithmetic meanDefault (computer science)Core dumpModulare ProgrammierungCartesian coordinate systemDifferent (Kate Ryan album)EvoluteSoftware development kitComputer configurationComputer animation
Configuration spaceComputer fileExecution unitDrop (liquid)Directory serviceAliasingComplete metric spaceProbability distributionLatent heatDatabasePhysical systemDefault (computer science)Normal distributionPlug-in (computing)Network switching subsystemPasswordStandard deviationDifferent (Kate Ryan album)Computer fileConfiguration spaceSingle-precision floating-point formatLipschitz-StetigkeitRevision controlFile formatDot productComputer configurationMathematicsDirectory servicePasswordCore dumpFormal languageCartesian coordinate systemPhysical systemImplementationProbability distributionSparse matrixFront and back endsLibrary (computing)Interface (computing)Arithmetic meanSimilarity (geometry)Electronic data interchangeSet (mathematics)Multiplication signLatent heatSystem administratorClefShared memoryDefault (computer science)Plug-in (computing)CASE <Informatik>Flow separationIndependence (probability theory)Slide ruleMessage passingSoftwareExecution unitProof theoryGroup actionAcoustic shadowCommunications protocolService (economics)2 (number)DatabaseNumberShape (magazine)Vapor pressureFile system1 (number)Series (mathematics)Installation artDigital photographyLevel (video gaming)Hydraulic jumpDisk read-and-write headClassical physicsGoodness of fitNeuroinformatikHand fanGodProbability density functionArtificial lifeJacobi methodPort scannerComputer animation
Default (computer science)Computer fileConfiguration spaceDirectory serviceStandard deviationPhysical systemSystem administratorRevision controlCore dumpAtomic numberCommunications protocolService (economics)AliasingComputer networkGastropod shellProbability distributionLatent heatLocal GroupAcoustic shadowConfiguration spaceDefault (computer science)Data storage deviceComputer fileUniform resource locatorComputer architecturePersonal digital assistantDirectory serviceECosPhysical systemDatabaseWordDressing (medical)Bookmark (World Wide Web)CASE <Informatik>SoftwareSystem administratorAxiom of choicePosition operatorMedical imagingPasswordInformation systemsWave packetStandard deviationMobile appGroup actionFlow separationLocal ringNeuroinformatikTerm (mathematics)Canonical ensembleProbability distributionElectronic mailing listRevision controlGoodness of fitReliefVirtual machineSet (mathematics)Video gameTable (information)Traffic reportingMultiplication signInformationHierarchyAssociative propertyCommunications protocolSinc functionTorusAreaFeedbackLattice (order)Bit rateOpen setMaxima and minimaAuthenticationGrand Unified TheoryForm (programming)Patch (Unix)File systemLibrary (computing)Data conversionAtomic numberIdentical particlesModul <Datentyp>Roundness (object)Expert systemGeneric programmingDifferent (Kate Ryan album)Functional (mathematics)Slide ruleAcoustic shadowFitness functionRight angleScaling (geometry)Shared memoryCartesian coordinate systemComputer animation
Associative propertyPhysical systemInterface (computing)Cartesian coordinate systemWeb pagePasswordProteinPlug-in (computing)Buffer solutionNetwork switching subsystemSuite (music)WhiteboardData managementDefault (computer science)SpacetimeData conversionFactory (trading post)Goodness of fitEmailStaff (military)OpticsMathematicsMotif (narrative)Online helpFeedbackElectronic mailing listDatabaseSound effectData storage deviceUniverse (mathematics)Series (mathematics)Multiplication signMereologyRight angleFlow separationAcoustic shadowGroup actionProof theoryCodeRoundness (object)Auditory maskingConfiguration spaceDemonNumberLecture/ConferenceMeeting/Interview
VideoconferencingHypermedia
Transcript: English(auto-generated)
Good morning, I Hear to get a lot of great talks about my quest cubic and transaction updates the last days already so We had to do a lot of changes in the last three years to make this great product things
From very small to very intrusive very big But the good thing is nobody noticed some people only now notice after two years the changes we made So What we did worked fine and helps the people but there is one big issue topic left and this are
configuration fights in case you are doing an atom are Update atomic update and that's what I want to speak about today. So my name is source and cookbook I'm distinguished engineer at Sousa. I'm also senior attacked responsible for slash and my chorus a
Little bit about the background At the end configuration fights this is something for every dispute this evolution has and RPM a standard has some support for configuration fights
If you don't mark your configuration file as package fast special Then it do all the things of the user will be overwritten with the next update If you mark it as normal config file and you make a change to your configuration File in the package then the one from the user will be moved away as RPM safe and or written if you
Mark it as conflict nor replace and the modified Configuration from the RPM is stored as RPM new beside of it So this hasn't changed for many many years So the sounds to me at the beginning first glance everything must be okay as people to finished it
But is it really everything okay? So after every update you have to look for RPM safe and app a new configuration fights to get your services working again and
Special thanks here for this people who? Continuously fix typos in comments and their configuration file mark SS config its mean after every update with a type of fix in a comment My configuration file is moved away and has the default one which is not working on my systems and have to go through all the
RPM safe and RPM new fights to find out what has changed again. Why is my service not coming up? So and then you have to share it match all the changes manually Luckily most of the changes are not that important or really visible to the service. It's continued to working But if you really didn't take care after every obtain it could be that your
Service will be insecure not work as expected or something similar Now we introduce atomic updates for the user with transaction update as our new system movements have other solutions for it And that's even getting more of us
so atomic updates are Either my update is applied fully correctly Or not at all there is no stage in between like half of the FM is currently updated Services are seeing it whatever You know if everything applies
Fine, and there were no mistakes You make a tomorrow switch to the new system and everything is there and running and if something fails You can do an easy way back to the altar often What does it mean for configuration fights? So
We create a copy of the current system and update this this includes the configuration fights of course and This also means doing the hidden update. We much or adjust the configuration fights with the new weapons Between this time and when the admin finally says no, it's a good point to activate or changes and the boots
You can do his own changes to configuration fights Which means you have before the boot visible configuration fights with changes and Not visible you have configuration fights with changes done by us as Linux decimator
Or as package are or upstream software package and they are going out of sync Is I reboot now then all changes made by the admin to the visible one after? Credit Applying the update I lost so he has to manually find them and redo them again
and Other problems are how does admin now that severe changes done? That's a conflict changed in the background How can he adjust them before the reboot so we have a lot of open? Questions here how to handle configuration fights correctly in our case of an update
There's also something called factory set of system D There was a block of bought it in the end It means I can delete etc. And with the next reboot everything will be
Recreated again and the system is in the state as I deployed it without any more changes Some people like this idea, but now Linux is a boot or did implement it Most likely because it's not really Tech able it's a lot of work. It's a lot of interest to packages, whatever I
Don't know exactly why Though this all together Leads me then to the Problem we are having today Which means mostly no accessible options have a Linux solution with a tumor updates
For example, it's open to the micros for us It's chorus fedora that had atomic or chorus. It's Ubuntu core so there are many and They all have faced the same problem how to update the configuration files in ATC and they all did come up with their own
Solution so which means it's different on every Linux is a boofin Which we reminds me a little bit of the times before we had the fire Here are his son not there on every Linux's roof in the configuration files applications
Everything was stored in another place and the father similar out was completely different so now if you have solution for a package for your distribution with atomic updates and if you speak to the Upstream developers, they say it's working for the user standard Linux is a boofins desktop server and
For atomic updates every body is doing something else. So I have to implement several ways Every time for only one distribution, so they are not interested in it So that makes it also pretty hard to come up or solve the problem for our products
so and this is our The gold I try to Solve or would have My goal is that
independent on which Linux distribution you are using This atomic updates the user foot always finds the configuration file in the same place as an example Most distributions atomic updates have their user database Not in etc, there's only a dummy or for the user kit one but somewhere on a user lip bass system or something else
I very often got tired Co-op is much more secure than my co-op because Co-op has only one user and that is rude Besides it. I don't think that having only one account and everything is running as one account is really secure
It's not true true and I always follow them. They are in user lip bass System or Bass they can find the real pass with a file So this is always surprising for the people Then know it from one distribution or the next is different and the next is again different so Users would find the configuration every distribution in the same location or with the same way that they know how to look for it
It should also get create guidance for developers that they develop new software in a way So it works from the beginning with transaction update For to midterm. I want to have a solution for atomic updates So for a small set of packages only likely use an open to the micro s
Long-term It would be good if we can do it for the whole distribution and not only for a few packages and That it is really consistent across So what I don't want to take the fear of some people are always here in talks about this
It should not become a requirement for all packages and you should not start now to adjust all packages to follow to the new layout If there is a package which has already solution for this like system D Don't confuse people by moving everything around today. This is not helpful if this
Is something people really like it will come From alone if not, then it doesn't really matter and if you think about a solution What are the requirements for it the one I created in discussions with my team and other people are It needs to be visible to the admin that configuration files got updated and that he may be need to look at it
It must also be visible for the admin which are his own changes that he knows if he has to merge something what he changed and in the best case it would be Optionally if the changes would be much automatically now, I want to come to some proposals
We have different kind of configuration files that we that's why we need more than one proposal We cannot do one for everything and not for every problem. We found a good solution yet But if you look at the standard application configuration files
There is a good solution. Look at how it system D is doing it The SIMD has user lip system D with the system distributor defaults Just ETC system D where you can overwrite it so you can copy the configuration file and adjust it
From user lip to etc. And then the your version is done and you still have some unmodified original version in user lip Or if you only want to overwrite one or two single values and if it's possible with the format of the configuration file You can create a dot D directory and Put only a file several files it which will write a single option at not the whole file
This all also helps you later to find out. What did I change? Because if you have a long File with let's say 100 options. It's hard to find out which you changed But if you have five files every file one option and you immediately see what you did change really there
Reads a look at the system D system D unit Manual page. There is a good example how this works like and how it would look like So at the first glance it looks like it's a lot of coding work
I have to touch every package every software to implement it That was my first impression when I started looking into this problems, too But if you take a closer look at open to the tumbleweed in etc, you will find out it's not that much work
At least not for the core packages Because most core packages have already something built in which is similar or also solves the problem But we don't use it For example pam we have etc pam D. We have user lip MD Nobody knows about user lip MD. I am as one of the old, you know expand
Maintainers, although meanwhile completely forgot that this directory exists and only find out by accident when looking at another Linux system who is using it So for pam, you only need to adjust our packaging and we have it already for more or less free This CTL you also have already a lot of directories user lips is CTL dot T
etc, this CTL dot T the packages could install their config file in user lip not in etc, and the admin could could overwrite our distribution specific settings in etc and always sees what he changes and he always sees what our
defaults are Edi config is also something similar. We use etc edi config dot D and it's not config dot D we install our it's not configuration files in the Meaning because
Now user will ever modify this file to be installed there So in my opinion, they wouldn't be an etc if the admin never touch them modify them or cannot even modify them These are only some few examples if you look at etc, you will find a lot of tools who have already dot D directories and
I'm didn't checked everything. Maybe they have already support For several months, but if not, it should be easy to enhance them to support it So the first goal we should look at is What was applications only support today to solve the update problem and enable it and adjust your packaging
That we can do that Another thing is they are for nearly every language config file sparses for Perl, Go, C, C++ Ruby and most very few but some of them already support the system D like
Setting 2 for example, I found one written in Go Go any You also have somebody in my team currently working on a C implementation of a library So there's only one config
Interface and then the library in the backend is merging all the configuration files for the application So that also helps a lot to adjust applications in an easy way and It's not really intrusive there Another different case are this I call it system databases
This are not real strictest book no configuration files, but every system has them etc RPC etc services etc protocols it's quite easy to move them to something on top will our user and We also have NSS Plugins which could look up at first and etc
And if you don't find the entry there look up in user if you find the entry there and if yes use that So that is really only a pecker thing think I Used a pass user fear default etc there
because this Pass this directory is already used by tumbleweed or was used by packages before I started looking in into this I Know from discussions already that some people don't like it. I continue to use it in my slides because it's already there and used but
The directory is something we also still need to discuss It's not optimal. For example shadow or Passivity Entry is not System independent don't belong to fear there could be other Configuration files which are the steam dependings. They don't belong to fear So maybe user etc would something better but more at the end
So etc pass with the etc group file. It's a shadow file To be honest, we didn't found a good solution yet We made a many proof of concepts one was also etc shadow dot D directory etc group dot D directory
It's quite easy with NSS plugins that all applications can read this merge and without any changes applications only to the NSS switch configuration file, but every time if you then think about
Changing a password creating a new user It's really a huge amount of work to adjust all possible tools there So the best we currently have and if somebody has better ideas I would be really happy to hear them So create the same accounts and user share
defaults, whatever normal accounts done by the user created an ETC This has a drawback if so Admin creates a system account. You can have a gained UID clef because they could be already in the hidden file something Use a NSS plug-in to read them
this does not really solve all problems and NSS compart still used by many people wouldn't work anymore and As I said with the example from core as users It's confusing if people don't see all passwords or users in etc anymore
So I need to know we are to look for the real one and how to look it up default locations I already said below user we need a way we are to store configuration files That people will find them Currently it's like pre file system. You know, he standard times. Everybody has something else
so it should be easy to find for user and remember for system administrators This is all in one place. Don't clobber user lib even more. There are already so many files and directories in user lib
That it's really hard to find something there anymore Find a solution which does not conflict with the file system standard or we need to adjust it I'm afraid we need to adjust it even if it is nearly dead I hope that you can reactivate it come to a conclusion there
the name of the directory for not confused administrator, so they should know what it is and It should be clear that this is the default location for the solution up supported supplied configuration files and not that this is the configuration files where they have to edit the file
They still need to do it in etc. As I said many Linux solutions have their own solution already Here is a list of what different solutions use. User fair default is what clear Linux and several
Tumbleweed packages are already using User fair base layout scale PEM not decoys is what's using used by coarsely container Linux Slough right able slash etc. Right able is used by Ubuntu core User etc is used by the micro as a redhead fit and fedora or cent OS atomic
user fair this config was a suggestion My currently biggest problem here is the share Because what do we do if applications are people Have something
Too specific then you cannot destroy it and share User fair miss is already used but I think using that would be even confuse people more because the usage Of all its use then and what is written in the file here. I send that is not really compatible
So That were my current favorites when I wrote the slides. Meanwhile, I'm not that true anymore. I First user defaults as top directory because it's already in use on the Tumbleweed but we're thinking about Pathway day password group shadow
They don't really fit it. The idea was to move it to use ellipsis image etc But that's really hard to find for people and even more confused in different places Meanwhile, I think maybe user etc would be The best choice as already used by fedora redhead and open sousa
micro-s But this is really something needs to be discussed in a broader round And now I'm already at the end Yes a long more detailed proposal in my github directory, I will also put the slides in there
So there's written much more of the background why some things are as they are or by things we tried already are not working And as I know questions from you suggestions ideas I'm happy about every feedback
So what I take from your talk is primarily We need more modularity in configuration files, so the tools
Which need a great configuration files should already provide a way to provide some modularity From my experience. There's also the way to go. So Just two remarks when we talked about authentication databases pass with the groups and so on
Maybe The problem isn't that critical because usually if you Distinguish system accounts from say user accounts in a bigger infrastructure the user accounts are not provided usually from local databases, but from a Directory or whatever for example using SSSD. So maybe this would be a way to
Circumvent those problems you have mentioned. Yes, it's also an idea to store them in ADAP, whatever that's also a reason why currently don't see it as critical to solve because really
if you have more than one machine, you normally either have very few accounts or Big network you have something like ADAP active directory or whatever forces The problem is really if the admin creates a user system account for his software You need to install for it. And then it there is a cliff the functions for that are not big
That's why I couldn't be ignored it. But this is something we would like to solve in a generic way for everybody The second thing is I'm not that sure but I'm also not an expert in that area whether the existing PEMD files really solve the problem of modularity in PEM
Have you some experience on that but maybe we could clarify this in a personal conversation Yes, and now so They don't really solve it If you have user PEMD, but there is also the include directive and with this is it possible to solve it? Yes, it's not easy for the admin
but It's a first step Okay, and I don't think that after I would say the PEMD well meant is that that many many years because Son who owns Protocol or the definition doesn't exist in anymore And nobody is willing to come up with a PEM version 2 or whatever because they are SSD whatever
So that is too much in use to really replace it. I One is already that the admin can overwrite it and still see what we are doing
But yes, it's as I said, not everything is solved This is just to make minor or major issues open But having a step doing the first steps in the next one is much easier Okay, and I think the last question then is for personal conversation Have you ever found a way to set the default you mask in a modular way? I haven't but
We can clarify this in personal conversation. Yes, I think it is a person Thank you. Thank you Have you also considered to change the way that password group and shadow are managed entirely? I
mean replacing the complete thing in a way So As I said, we made several proof of concepts. There are ideas to store it in a database and have a demon Fetching it out of it
We are not really happy with all one if somebody has a good idea doing something completely different. It's also fine, but There are some things to remember one thing is there are two interfaces, which Number one, which is reading it. It is an SS interface of gdpsi
So everything for which you can provide NSS plug-in is fine to read it The second thing is and it is a big issue we always see You need you have a lot of tools which modifies a password which modifies our account which make changes to it and
We were looking at to get Accepted more easily by people is to find something that they don't Fear they need to learn something company and have to touch 100 package Applications and give right big parts of their code
so There are many options. There are many ideas. Nobody at the time to come up with a proof of concept which was really Solving the issue and would be accepted by many people if you have a good idea How to store it in another way which solves the problem? Great, I'm really get to if I if you could tell it to us if you can discuss it
I'm really open there and there is no no go except you don't want to touch the current existing interfaces more questions
Okay So I will submit this the next days to the factory mailing list and hope to get there More ideas comments that we can start to make changes Only though as Feedback in this round if you would say we start for the time will be modifying or modifying all applications
configuration fights Would you? Support it Would you have to move it? Do you think it's a good idea to move it modularize it or do you think now I will not touch my packages I will not help so who would be in favor and
Help moving this forward in with his packages or likes idea only one two Okay for the minority. So who doesn't care at all? Okay, less the minority you don't support it. You don't like it or
Okay, nobody doesn't like it So many people think need to think more about it Then I want to thank you And I hope to more longer food for discussions on the factory mailing list. Thanks