Config Model and configuration upgrades during package upgrade
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 97 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: 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 | 10.5446/45688 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Projective planeObject (grammar)Configuration spaceCopyright infringementForcing (mathematics)Physical systemConstructor (object-oriented programming)Ferry CorstenMereologyUniform boundedness principleMultiplication signStaff (military)Moment (mathematics)Single-precision floating-point formatRule of inferenceElectronic mailing listPower (physics)Disk read-and-write headDomain nameDifferent (Kate Ryan album)Centralizer and normalizerBitComputer chessTheory of relativityUtility softwareOrder (biology)ConsistencySound effectRight angleGoodness of fitRevision controlComputer fileWordReading (process)Directory serviceSoftware maintenanceSoftwareComputer animationLecture/Conference
02:35
Maxima and minimaPoint (geometry)Logical constantOperator (mathematics)Multiplication sign2 (number)Metropolitan area networkComputer programmingScheduling (computing)Moment (mathematics)GoogolPhysical systemElectronic mailing listFrequencyPhysical lawSeries (mathematics)Annihilator (ring theory)Workstation <Musikinstrument>Execution unitGroup actionField (computer science)VotingAxiom of choiceContext awarenessPerimeterLatent heatSuspension (chemistry)Vertex (graph theory)Sound effectFigurate numberFamilyDemosceneCausalityOrder (biology)Matching (graph theory)Real numberHydraulic jumpWage labourProcess (computing)Ideal (ethics)Level (video gaming)InternetworkingInformationHand fanSoftware testingSpeech synthesisWeb pageSymbol tableMilitary baseCasting (performing arts)Digital photographyRight angleSubject indexingTournament (medieval)Noise (electronics)State of matterAuthorizationRoundness (object)Software developerView (database)SpiralBitChainSpacetimeGoodness of fitMusical ensembleCASE <Informatik>Bit rateMereologyTerm (mathematics)CodeExtension (kinesiology)Configuration spaceINTEGRALEndliche ModelltheorieParameter (computer programming)Universe (mathematics)Flow separationValidity (statistics)Semantics (computer science)Default (computer science)Graphical user interfaceWritingLoginReading (process)Set (mathematics)Social classObject (grammar)QuicksortDescriptive statisticsTraffic reportingComputer fileElectric generatorInteractive televisionRootData structureConstraint (mathematics)Server (computing)PermanentElement (mathematics)Interface (computing)Cartesian coordinate systemWeb 2.0Cursor (computers)Library (computing)Type theoryTheory of relativityIntegerProduct (business)Key (cryptography)Software maintenanceDistribution (mathematics)Network topologyParsingComplex (psychology)Rollback (data management)Revision controlOcean currentMechanism designComputer animationLecture/Conference
11:45
Fiber (mathematics)Endliche ModelltheorieConfiguration spaceWikiOrder (biology)MultilaterationData structureProcess (computing)CodeParameter (computer programming)Set (mathematics)Matching (graph theory)Slide ruleSocial classMarkup languageSource codeNetwork topologyComputer fileKey (cryptography)Web pageCartesian coordinate systemInformationDescriptive statisticsDefault (computer science)Boolean algebraGraphical user interfaceArrow of timeType theoryElement (mathematics)Sign (mathematics)File formatTheory of relativityConstraint (mathematics)Declarative programmingOnline helpSinc functionExpert systemWebsiteAuthorizationPhase transitionPersonal digital assistantPhysical systemWave packetService (economics)Context awarenessLevel (video gaming)Computer programmingExpected valueSemiconductor memoryPoint (geometry)ConsistencyView (database)Suspension (chemistry)Ferry CorstenSeries (mathematics)Artificial neural networkPlanningMetreRoundness (object)Forcing (mathematics)FrequencyResultantSequelQuicksortMultiplication signChemical equationFlock (web browser)Flow separationMoment (mathematics)Student's t-testLecture/Conference
16:56
Matrix (mathematics)Configuration spaceComputer fileHuman migrationWell-formed formulaFront and back endsEndliche ModelltheorieVector spaceMetreMatching (graph theory)WritingReading (process)EvoluteModule (mathematics)Coefficient of determinationParameter (computer programming)Line (geometry)Social classAngleDefault (computer science)Type theoryCartesian coordinate systemInformationRootDescriptive statisticsResultantPasswordRevision controlProjective planeSequenceLevel (video gaming)WikiCASE <Informatik>Drop (liquid)Metropolitan area networkFeedbackBitSet (mathematics)MereologyOrder (biology)Physical lawMoment (mathematics)Group actionPivot elementComplex (psychology)Water vaporTheory of relativityFunction (mathematics)Associative propertyGoogolSurvival analysisChainMultiplication signContext awarenessSpecial unitary groupCrash (computing)Decision theoryMusical ensembleState of matterDisk read-and-write headSymbol tableWeightLimit (category theory)DivisorPower (physics)Computer animationLecture/Conference
22:02
Device driverContext awarenessGroup actionElectronic mailing listField (computer science)Software testingPhysical lawFilm editingVotingEqualiser (mathematics)Position operatorEndliche ModelltheorieDrill commandsCivil engineeringBoss CorporationDisk read-and-write headCASE <Informatik>Process (computing)Error messageMachine visionMountain passMoment (mathematics)Source codeFamilyMultiplication signWebsiteTraffic reportingOcean currentForcing (mathematics)Right angleCausalityMatching (graph theory)Physical systemHand fanMathematical analysisAsynchronous Transfer ModeMereologyException handlingParameter (computer programming)Configuration spaceContent (media)Computer fileHuman migrationEvoluteDistribution (mathematics)MathematicsProjective planeBitDefault (computer science)ExpressionPower (physics)Rule of inferenceLine (geometry)Network topologyWell-formed formulaOrder (biology)Mixed realityVariable (mathematics)Social classLatent heatAxiom of choiceUser interfaceType theoryBoolean algebraData structureINTEGRALLevel (video gaming)Data modelSubject indexingReal numberMetropolitan area networkLecture/ConferenceComputer animation
27:48
Profil (magazine)Level (video gaming)Point (geometry)Configuration spaceMultiplication signUniform resource locatorSource codeGoogolConstructor (object-oriented programming)Library (computing)Data structureComputer fileExclusive orEndliche ModelltheorieServer (computing)StapeldateiCache (computing)Mobile appComputer animationLecture/Conference
29:06
FrequencyFirst-order logicAverageComputer programmingSatelliteMereologyFiber (mathematics)Source codeBuildingVotingGreen's functionConfiguration spaceParameter (computer programming)Mechanism designFlow separationProjective planeEndliche ModelltheoriePlug-in (computing)Instance (computer science)INTEGRALComputer animationLecture/Conference
30:07
Link (knot theory)MathematicsThread (computing)Parameter (computer programming)Default (computer science)2 (number)Computer-assisted translationDemo (music)VotingProcedural programmingCASE <Informatik>WordComputer animationLecture/Conference
31:12
Data managementDrop (liquid)Multiplication signSound effectService (economics)Observational studySuite (music)Exception handlingMobile WebEndliche ModelltheorieType theoryPeer-to-peerStatisticsData recoverySoftwareSocial classAngleWeightWordMusical ensembleRight angleResultantHacker (term)Product (business)Source codeState of matterFiber (mathematics)Loop (music)Sinc functionInstance (computer science)Default (computer science)Configuration spaceParameter (computer programming)Line (geometry)EncryptionFerry CorstenVirtual machineComputer fileDifferent (Kate Ryan album)Insertion lossSemiconductor memoryProjective planePatch (Unix)Order (biology)Electronic mailing listSystem administratorMechanism designRevision controlReduction of orderInteractive televisionMathematicsCartesian coordinate systemGraphical user interfaceLoginAnalytic continuationSet (mathematics)Regular graphFeedbackFront and back endsElement (mathematics)Flow separationFlagRandomizationComputer animation
37:19
Point (geometry)Software bugSoftware maintenanceEndliche ModelltheorieServer (computing)Configuration spaceRegular graphComputer fileLocal ringCartesian coordinate systemDescriptive statisticsData structureLimit (category theory)Revision controlDigital watermarkingFormal languageSpherical capClient (computing)CASE <Informatik>Android (robot)Workstation <Musikinstrument>MetreValue-added networkArtificial neural networkOrder (biology)Multiplication signGroup actionLogic gateComputer animation
39:21
Computer animation
Transcript: English(auto-generated)
00:00
Okay, welcome to this presentation. I'm going to talk to you about the project I've written, which is named config-model. And I will talk about how it can be applied to configuration upgrade during package upgrade. Before going to configuration upgrade, I will explain to you why config-model and the objective of this project.
00:24
The basic usage and principles of config-model and then how it does apply to package upgrade. So, how many of you have installed the Linux system for your friends, family, neighbors and so on?
00:46
How many of you does in administration? Why? Is that configuration is part of the project, configuration of the software installed? For a casual user, like my mother-in-law, I've installed also the Linux system for my mother-in-law.
01:04
Configuration, she cannot do it, she won't and she doesn't understand it, so I have to do the administration. So I was thinking, why couldn't we make the configuration easier with the GUI, the HEPs and so on? So that's why I've created this software.
01:21
So for a casual user, upgrades are even more difficult. Sometimes you have a surprise question, for instance, with the CUCF you can be asked, do you want to keep your own version of the configuration? Do you want to keep the maintainer's action? What is the maintainer, by the way? And do you want to merge or show you a leaf?
01:42
What is the leaf? It's complicated, and then I have to go to the documentation to see what's going on and to modify the configuration file. So a usual configuration upgrade for casual users is very difficult. Even worse, sometimes you have to edit a file outside of your own home directory.
02:01
What? Go outside of home? It is very difficult. I have to read mind pages, tons of mind pages, very difficult to understand. Even worse, sometimes I have to ensure consistency between configuration files. If I just set something here, it will be reflected in another configuration file. So it's also difficult for casual users. And then you have spurious files.
02:22
I won't use the words that Jeff used the other day. On your system, in slash EC, you have rpm-save, rpm-new, dpkg-new, dpkg-new, all those are files which can be left there. And if you want to manage your configuration, you will have to merge them manually or remove them manually.
02:46
Even basic configuration will also be difficult. I've talked about this sooner. So one of the objectives of the config model is to make the configuration upgrade mostly transparent to the user, no interaction.
03:02
So this steps should handle most, if not all, configuration upgrades But sometimes the user will still have to configure the system. So I provide a graphical interface with integrated health, meaningful default values,
03:21
validation, semantic validation of configuration data, even if there is a relationship between parameters. Several levels of skills, like on the XEEN configuration interface, where you can be beginners or help to master the universe. So I was more modest, it's just beginners to master.
03:42
And provide a search capability to search in parameters, to search in the parameters value, or even sort recently about searching in the integrated health. So if you hear something about a configuration, have a keyword, you just search for the keyword, and the interface will guide you towards the right parameter.
04:02
Second objective. Do not put all the work on the developers or on the package maintainer. See, it's a configuration tool and the upgrade mechanism must be easy to maintain in order for the developer to adopt them.
04:23
So I want to avoid dedicated validation code. A dedicated validation code is hard to write and almost impossible to maintain. I want to base the validation on some kind of data data, which is a configuration model, which means all the specification of what's right or wrong in the configuration
04:42
is written as a data structure. It could be a VSS, currently it's a data structure. I want also to generate interfaces. Currently I generate graphical interfaces, cursive interfaces, and you can also interact with a config model, with a command line, and interactively, like if you were on an old model design
05:01
or on a Cisco system. Models are also specified to provide, to help, to perform the upgrade of configuration from old version to new version, by migrating all relevant data from old syntax to new, old semantics to new semantics.
05:21
Given the talk that was before, I'm beginning to think about ways to perform also rollback of configuration, by going from a configuration end to older configuration using old syntax and old semantics. So I will have to think a little bit more about this because it's tougher than just doing upgrades.
05:40
And also for the developer not to be, for the developer's work, maintainer's work, to maintain all the model works, to be not too hard, provided also, sorry, a QI to create and maintain the configuration borders. Also, the model is not everything you need.
06:01
You also need some way to write and read and write configuration files. So I've tried to minimize the code needed to write, read and write configuration files. So I use sometimes the existing library, like the config.ojs, behind config.ojs, which is a very good product to read and write configuration files.
06:23
So, and also I provide basic classes to help configuration. If you have to write dedicated code, like OpenSSH for instance, I've written a class to read and write OpenSSH files. I've provided basic class to have this. So it's just a reader or parser to just read the data, put it in the configuration tree, and that's it.
06:46
Okay, so here's the basic design, in fact. I've talked about the model here. Also, in blue, in brown, it's provided by config model. In blue, it's provided by the upstream maintainer or the distribution. So a guy can create a model
07:01
and create a configuration tool. And in green, it's provided by the user. So the work of the upstream maintainer or the end packager will be to create a model, create a writer, and create the reader, or reuse the relevant libraries. Config model will use the model
07:22
to create zero interfaces. Here it's command line interfaces, cursor interfaces, graphical interfaces. And I've thought about web interfaces, but I didn't have time to do it. Help would be welcome there. On the other side, the application here,
07:41
you have the configuration file, which will be read by the reader or written by the writer depending on what's stored in the configuration model and depending on what was entered by the user on the interfaces. If you have questions, feel free to ask me.
08:00
So what is a model? First thing to understand, most configuration data and configuration file can be represented as a tree structure. Sometimes you have more complex relations than a tree. But let's start simple. Configuration is a tree, a bit like an XML file. So you have to define, in order to validate the configuration,
08:21
you have to define what is in the tree, what is the structure of the tree, and what values which are represented in the leaf, what are the values and constraints of the value. So the model defines a tree structure. A class represents a node of the tree. A configuration class represents a node of the tree. For instance, here you have the SSH class,
08:41
which is the root node of the SSH configuration. And a parameter is represented by a leaf. A leaf is just, it is here, a leaf will be stored, it will be shown as an element of the SSH configuration class. These are all the parameters to have, here you can see the read config and write config,
09:00
so you specify how to read and write here. So each class contains a set of elements, here highlighted, which represent the parameters, an optional specification to read and write configuration. I said surely because
09:21
read and write specification is mandatory for the class that represents the root of the tree, but is optional for all the nodes. So it's a way to be able also to use the configuration tree to store them in several configuration files. So here is a snapshot
09:41
of the GUI to create configuration model. So, simple element, each element has a type, it can be a simple leaf, so it's a simple parameter, or it could be a hash, it's a parameter which has several keys and several values, it could be a list,
10:01
because there is no notion of keys to access this parameter, or it could be another node, which means you have a complex tree structure with several levels. Each leaf has a half constraint, whether it's a type, whether it's an integer or a string, maximum value, minimum value,
10:22
mandatory, not mandatory, and so on. Default values, there are several types of default values, and there are default values which are embedded in the application, where I talk about upstream default, there was a big discussion with Stefano Zecheri, I don't know if he's here, and upstream default
10:41
means the application node or the default value is encoded in the application, so you don't have to write it in the configuration file. The default value will be written in the configuration file. A default value can be required, for instance, by devian-policies. For instance, in devian-policies, or devian-recommendation, the permanent root login
11:01
of the SSHD server is always set to NO. So this is an example of a default constraint, default value. Whereas, for the root login value for upstream default is YES, because SSHD by default permits root logins. There is also, in the model,
11:21
a description and a summary to help people for integrated help, or maybe you could generate reports of what's in the configuration, mixing the integrated help, which is the description of the parameter with the actual writing, all sorts of things are possible here. You also have the experience level, the skill level, beginners to master,
11:42
and the status. The status is the first step to be able to manage upgrades with config model. So you have the normal status, which means the regular parameters, and you have also it, okay, it's on its way out, config model still doesn't understand it, but the application may not understand it.
12:01
And the parameters, with another solid status, should be reused by another parameter during the migration, the upgrade process. I will talk about this a little bit later. Here on the right, you still have the GUI, the model creation tool.
12:21
Okay, so, what work do you have to do to create a model? First, you have to read the documentation in order to find the structure of the tree. How is the tree structure? It's not always obvious, just reading the configuration file. For instance, with the CSHD, you have an impression, it's just linear, but with the match,
12:41
with the match directive, in fact you define another class because the match will apply on a set of hosts, and all the parameters below the match declaration will apply to this host. So it essentially looks flat, but in fact, it's hierarchical. And you have to identify
13:01
the configuration parameters, the constraints and the relation. This process was, I was describing in a news magazine in France, an opportunity for most of you in French last year, so if you want to learn more about this, you could also read a news magazine in France.
13:21
And then also, after that, you have to find several valid examples of the configuration file, because it will help you verify that you correctly understood the documentation, which is not so easy most of the time, and it will be helpful for the non-aggression taste of your model.
13:43
In short, in fact, the configuration documentation that you will read in the web pages will be translated in the format understood by a config model. Structure and tree structure is translated into a set of configuration classes. The configuration parameters, which belong to the classes you have identified,
14:01
will be into LMS. And constraints are able to be used here. So for instance, the SSH class is the SSH config of your .SSH file. You can define... You have enabled SSH key sign parameters, which is the element's name, and it's an element.
14:21
So here I've shown you the data structure which is generated by the GUI. It's more nicely in the slide than the GUI, so that's why it's written here. But you will find this in the GUI, this in the GUI, and all this in the GUI also. So here what we have is the class SSH. We have a parameter enabled,
14:40
a SSH key sign, which is a leaf, which is a boolean. And the default value understood by the application, the SSH gradient, is zero. So if you don't specify in C, it will be zero. And then you have the description. If you want more information on model creation, I've written a wiki page on the source code wiki
15:01
of the site. Ok, so writing the data structure is not fun. For most people, even for co-developers, big data structure is not fun to write. So that's why you have created the GUI that enables you to specify models. So here you
15:20
read, you see, or you don't see the class SSH element, enable SSH key signs, the value type boolean, and so on. The green arrow means that the value was entered by the user. However, it's not the default from the application itself. So here, there were three parameters entered by the user and there is a description below.
15:40
So this matches the data structure I've shown you just now on the slide before. Any questions on the model decoration? Yes? Why are you using code instead of markup to define them? You mean the slide I've shown you before? Because this code is used inside config model.
16:00
I could use markup. It's a... Anyway, I need something which is a structure so the code is easy to pass and very fast. I could use XML or something else. It would be exactly the same methodology. Okay, so when you create a model, you have also to think about
16:21
the future configuration of the upgrade. The third thing is to avoid introducing new parameters. It may be obvious, but often beginners tend to abuse the needs of configuration parameters. So don't avoid at all costs. But sometimes you still have to introduce new parameters.
16:42
First, think really hard about the parameter name and its value. Meaningful parameters and meaningful value is a great help and it will avoid you writing lots of documentation and explanation next. So think really hard about the new names and the possible values
17:01
of the parameters. Then, provide default values. So the application can work with an anti-configuration file. By default values, in this case I mean written inside the application. Or, if you need, provide them in the model. In the model when you apply the config edit command all the default values will be written in the files
17:22
and the user will see nothing. It will be as if the default value were understood by the application. So it's a way out but you must provide default upstream values or default values. Then the configuration will be transparent. If you provide the mandatory parameters without default value the user will have to step in to configure it.
17:41
So that must be avoided. So, if needed model and backend backend is the name for read and write backend classes. It can specify how to replace a value. If you want to change the value from a non-meaningful line to a new meaningful line, a continuous
18:01
line can take care of this for your user to read the upgrades. You can specify obsolete parameters if you want to get rid of badly named parameters you can put the status obsolete and then you have to specify how to migrate it from the old parameters to the new one. Using the migrate from parameters
18:21
you can use the formula so if you have to put more complex migrations than just preparing the value. For instance, if you want to have a configuration file with an imperial matrix and you want to go for two meters you can use a vector by something in the formula to change the values from
18:40
an imperial matrix into a regular matrix. Well, apologies to American people. By playing with the backends, because you can specify several backends which will be tried in sequence. You can also migrate the value from one syntax to another.
19:02
For instance, if you have an old mini file, you can read it within the backend and save it back as XML. So you can change completely the syntax of a file if you want to go for a project version 2.0 with XML configuration. With this you can migrate all configurations to the new one.
19:24
For more information I've written a paper on the Debian wiki on how to apply a config model for Debian packages upgrades. It's still a work in progress, but I think it's promising and I got some people, lots of people
19:40
interested. So in the end, what the user will see? Here's the configuration GY that the user will see. You will see here the SSB class with the allow user parameter, allow TCP forwarding long middle max-testup, and so on. So this is the GY SSHD GY which is shown to the user.
20:01
And this is generated from SSHD model. So here you see that I've changed the log level which is there both instead of the info and here's the parameter root logging which is no instead of yes. And we are okay. And here you have the value of the highlighted here you have the value info
20:21
which gives you the type of the parameter which is enumerated type which is yes first code, password result password, stuff like that. And the built-in value in the application, the built-in default value is yes. And here's the description.
20:41
And this is generated from the model. By the way does any of you know why this GY looks like the GY configuration edition tool? Because I've written a model of config model.
21:03
I've eaten my own dog food. The name of the module if you are interested in looking at it, but don't do it first. It's a config model itself. Okay. Package upgrade. What's the status? On Red Hat, configuration evolution
21:21
may leave some FMU or FMF files. And then you may need to merge them manually with your actual configuration. On Debian, configuration will trigger questions which are often picked or generated by UACF. Do you want to keep your file user-deep, do something else?
21:42
Or you can also have a spurious file that can be un-saved but is now duplicated in new files. In all cases, matching configuration will require good knowledge for your user. And that does not apply to my other angle. So yeah, that's why I've created config model.
22:03
Okay, so here's the proposal. Config model can be used to merge user data for the old configuration file. And you can also put package and upstream evolution inside the model using the migration, the obsolete status, and so on. So the evolution of the model, of the configuration
22:21
can be written in the model specified with the status obsolete and migrate from parameters. So once you have defined these models with the migrate instructions, the obsolete stuff, it can be applied to the configuration to migrate your configuration
22:41
into the new one. The merge capability can be easily implemented by upstream project. It's essential to solve changes related to the model. The model can be patched, modified by distribution during the big process, or when they use
23:01
their packaging work. It can be also modified sequentially by direct distribution and no big source code index. So each level of integration that you have here from upstream, downstream can improve the model and tune the model to its own needs, to the own needs of the distribution and the needs of the users.
23:22
Again, it's the same proposal on package configuration upgrade. So here's an example. I use the data structure instead of the GUI, it's more clear and I can without alter what's not modified. Here's the own SSHD parameter which is named keep-alive. The man on the dot mentions
23:41
that TCPEK keep-alive was the name of keep-alive before. So here's a real use case. Keep-alive is a linear type and the choice is no or yes. I don't use the boolean because SSHD specifically wants yes and no and not just 0 or 1. So it's a way of doing it. Status is deprecated.
24:00
It's almost obsolete. I need to clarify this. And the type is leaf. This is the old parameter what once contained its own model. When I write the new model, I introduce the new TCP keep-alive parameters and specify how to migrate it. So again, I have the value type the type leaf
24:21
and the choice which is yes or no. And here's the migrate-from specification. Here I define the formula and variables. Variables means they refer to other parameters in the configuration tree. This is what is complicated. You have here where to find this variable. I go back, I go up
24:41
whenever is the configuration tree so I go in the SSH class and I use the value of keep-alive. This is stored in this keep-alive variable which is used here in the formulas. Here the formula is very simple just put keep-alive in there. So inside the two lines specify the default value
25:01
of keep-alive is compiled from keep-alive. And when the configuration file is saved back on the system the status deprecated means that this one will not be written and since this one has a default value calculated for migrate-from
25:20
it will be written back in the configuration file. Of course more complex migrations can be used with the formula and you can have several variables so you can mix parameters in order to perform a migration for very hairy cases. You can use a full power expression
25:44
if you use there is another parameter which is my name use-eval but I didn't want to force power on everybody. But it's possible. OK. Practically how can this be done?
26:01
For Debian I've written a th-conf model upgrade and this is just the line you have to add in your Debian rules party. Just specify the model name that must be used to perform the upgrade. The name of the package which will be required in this case is the name of the package that contains the model that it could be model-sshd-cur.
26:23
And by default this will apply to all the packages built with OpenSSH which needs to be refined a little bit but there are some mechanisms. My red hat. I don't have any red hat helpers so the trick is to run
26:41
in post-install this command which will use model-ssh specify not to use any UI no user interface and force the save of the configuration. I say force the save because here the user does not enter any parameters but just the thing to be done is to upgrade so the save will
27:00
re-write the file back using all the migration parameters that are declared in the model. If there is no migration parameters in the model the file will be written back with the exact same cementing content.
27:24
Basic config model does not keep commands. If you use OGS back-end you can't keep commands. But from the tries I've made for upgrades and so on as soon as you add new parameters you don't know where these new parameters will be introduced so the commands
27:41
can get messy. But it can work with OGS. Ok, what models are available? I have written OpenSSH APROX which is Debian cache server for Debian packages
28:00
config model in config model I've written cameras in XOR because cameras were written by one guy but I just have the model and it no longer works in it. In XOR I've written the model for XOR 1.4 but XOR is moving too fast for me to catch up.
28:21
XOR does not work anymore. Maybe I will have some time to do it. By chance you have .ini file syntax with those .ini files while data structure I'm currently working on YAML and there's a whole OGS library which can be used from config model.
28:41
Community Debian packages I maintain the Debian packages with Debian team with Gregor and John Z Append packages are under construction are constructed Mandry app packages are done and I've made some proposal to batch for the edge config for package and so on so I want to experiment this configuration with Debian. And there is an article
29:02
named New Magazine in French, unfortunately. Future projects and search parameters lead to add these annotations which means comments but introduce the difficulty as to where to store them. It's very difficult to store them because it will mess up
29:21
systemic comments. So I still have to think about this one. Backends, green and white parameters I need to work, maybe OGS or YAML would be XML, could provide XML quite easy. So I need people to have I need integration so it's done for Debian
29:40
it's done for Red Hat I must work on multi-level configuration for Apache, for instance plugin mechanisms of several people can work on both and integrate them together and define a big mechanism for this configuration integration, for instance, when you add GraphQL, Jupyter and Apaches, you will plugin a few bunch of configuration
30:01
and how to manage these configurations through coffee model I don't know yet. I need to work on this. Here are the links for references. If I have time, I have a small demo.
30:43
So here you have a cat which is done every two seconds on my HTTP copy. I've put default parameters with keepalive and in your host to know, etc. So I want to keep, to perform the thread
31:00
I talked to you about change keepalive to TCP keepalive. So here we go.
31:38
Sorry about that.
31:41
Here we go. So I've run the config edit model. I've mentioned there is stuff in order to be able to catch a class locally in the configuration file but you see the UI custom and state. now you see that it tells you that keepalive was deprecated
32:00
and here the file you see has a TCP keepalive or change TCP keepalive. Here I've not used OTS backend so the commands are lost and the file is reformatted. Now there is a new policy I want to
32:21
set permit foot login to no in all the configuration files of my users. So I patch a model with coffee model edit so here I introduce the class ssh gelement permit-foot-login default value is no. And upstream default is set away with reset.
32:41
So here I've patched the model This could be done for instance when packaging upstream project. I will show you the difference in the model.
33:05
This line upstream default was removed and default was added here. So the model you can see the effect in the data structure. Packager could either use regular patch mechanism or could use a configured model edit.
33:21
I think configured model edit is safer, more resilient to upstream change in the model. Now when I do the upgrade permit-foot-login is updated and now you see the value is added and set to no
33:40
without user interaction. And the old values are still kept. Now another useful policy I want to reduce default cipher list. So again I patch the model with configured model edit specify the class the element ciphers, the default list
34:01
now is the AES 1.2.8 and so on stuff like that. So the model will be patched again. OK, continue. We see effect on the file. We see effect on the file. We have the cipher list
34:20
also updated in the configuration file. This configuration edit applications can be scripted also with a simple command like here I will run config edit and set directly new parameters with ignore-host equals yes.
34:42
The new parameters are in the configuration file. And when with the users here from this stuff here is the graphical configuration the GUI and here you can see the parameters that were just updated with the current value. And we see that it wasn't updated.
35:02
And if you want to change back maybe here I go back to the standard value and then say no.
35:21
Question? I'm curious, so if I'm editing my memory loss machine and I want to add new parameter manual to this outside config model like x11 forward and yes then you decide to issue a new update, will my machine be maintained? It will be maintained.
35:40
The default values introduced by the data policy will be written in the file only if there is nothing in it. If there is already something or some user data, the user data will be kept. And also it should be too difficult to just add a new key value here in the configuration as like a comments flag so that those comments are written and maintained because those are
36:00
certainly valuable. We could have some kind of convention to write comments and to be able to parse it. The problem is, if there are random comments from Sysamin I don't know how to treat them. So for the annotation I was thinking about storing them elsewhere but then I have to decide
36:22
probably the best way would be to store them elsewhere and use OGS to keep the Sysamin comments in the configuration file and keep the annotation which is commented in the GUIs separately. That's a possibility. I need user feedback on this. If it would be useful I will implement it. If you think it's useful. What does happen if some user
36:42
or administrator decides to change the configuration file in a way that is not covered by the model? How does conflict model react to that? It will exit an error. By default it will exit an error. The problem is how conflict model can know whether it's a new parameter
37:02
or whether it's a typo. I agree that it's a typical problem. I'm not sure if that behavior is the best one. Since the problem I cannot decide whether it's right or new, whether it's wrong or new. I just exit. At this point we might consider
37:21
it's a bug in the model and send a request upstream or to the maintainer to update the model because the model in this case will not have followed the upstream application. Next question. On what packages are most best suited for this conflict model?
37:42
Which packages would you think would make more sense or less sense? All packages have relatively simple configuration like CAPs. I know that EXIM does not fit because EXIM uses DSL as a configuration language and it's not a regular configuration file.
38:01
It's a kind of description of the behavior of the application. Most of the applications I think could go into conflict model. Even as a server application like SSHD, CUPS or user application clients you could also handle a local configuration file in the .5 when you go with it.
38:22
I don't know what are the limits frankly. I think most of them accept the most complicated one and the most intricate one. It's whether you can find a trace structure in the configuration file and then it's good. If it's not easily maintained the trace structure or if it's too complicated
38:42
that they are using the configuration file it's easier. Then it's not good for this application. EXIM is a perfect example. Minus three minutes okay, I'm down there. Beyond the watermark. Okay.
39:02
Another question? It's in Sipan now. Sorry? It's in Sipan and in Ligand unstable. And probably in Mount River I don't know how well today. And it's coming in Federal. For Federal
39:21
ask Emmanuel Simon and you will do it.