Linux registry project

[Haden]

Today I've stumbled on Linux registry project.
I was skeptical at first, but after reading docs was fascinated how simple,elegant and powerfull suggested solution is.

Wanted to hear your thoughts about it.

{"4. Advertising and advocating the project" 😉}

 

[Sunner]

Originally posted by: Haden
Today I've stumbled on Linux registry project.
I was skeptical at first, but after reading docs was fascinated how simple,elegant and powerfull suggested solution is.

Wanted to hear your thoughts about it.

{"4. Advertising and advocating the project" 😉}

Well, I'm sceptical, but then, I'm sceptical about most anything 🙂
So long as they keep to text files, and a sane system(not the way Windows does it in other words), I guess it could be a worthwile effort.

 

[n0cmonkey]

Look into /etc/fstab file. Now look into /etc/modules.conf, /etc/passwd, /etc/ssh/sshd_config, /etc/httpd/conf/httpd.conf. I see here two terrible problems:
1. They don't have a common file format.

They hold different information, of course their formats are different.

2, Their localization in the filesystem may be different from Linux distribution to distribution.

Ummm, no. The locations should be the same: /etc.

When two different softwares want to integrate themselves, it is programatically very hard to read, understand and correctly change its partner's configuration file. Think about installing a third-party video driver in XFree86, a new Apache plug-in, etc, and letting this new piece of software do the integration automatically, instead of the sysadmin vi the configuration file, understand and change it in the right way. So basic software integration is a pain today for ISVs (Independent Software Vendors).

That's why man was written.

Different distributions use to put different software configuration in different places with differente formats. A regular SuSE system administrator, for example, will be lost when asked to work in a Debian or Slackware system. Think about the most primitive example: network configuration parameters. Each distro has its own approach.

Isn't that why there are different distributions?

A system administrator must know all these formats.

man.

There is no way to know today what was changed in a specific configuration file. If /etc/shadow file time changes, there is no way to know if the change was related to nobody's or root's record.

diff

High-level system administration GUIs (webmin, redhat-config-*, SuSE's YAST, etc) are just a dream today. They can never track successfully all changes that happens in the format of the configuration files of such a rich diversity of Open Source software (httpd.conf, smb.conf, modules.conf, fstab, etc, etc, etc). The approach of some of them is to keep the configuration ideas in a private database and regenerate the specific configuration file whenever a change happens in this database. Welcome to the inconsistency nightmare.

Sounds like a distro problem.

A registry would set Linux back 10 years. Bad idea.

 

[silverpig]

I don't like the idea of a registry. I like editing my fstab by hand, or my grub.conf.

 

[Nothinman]

Ummm, no. The locations should be the same: /etc.

I believe by localization they mean language, character format, etc not position.

When two different softwares want to integrate themselves, it is programatically very hard to read, understand and correctly change its partner's configuration file. Think about installing a third-party video driver in XFree86, a new Apache plug-in, etc, and letting this new piece of software do the integration automatically, instead of the sysadmin vi the configuration file, understand and change it in the right way. So basic software integration is a pain today for ISVs (Independent Software Vendors).

This something that groups like Debian have already taken care of for the most part and a registry is only one part of the real fix.

A registry would set Linux back 10 years. Bad idea.

I don't think it's quite that bad, but it seems that they're exagerrating the problem. A common API for storing/retrieving configuration settings wouldn't be bad, but it's already been done with GConf. And on top of that they need each OSS developer's cooperation to use the API which I doubt will happen any time soon.

 

[n0cmonkey]

Originally posted by: Nothinman

Ummm, no. The locations should be the same: /etc.

I believe by localization they mean language, character format, etc not position.

Oh 😱

Shouldn't the language, character format, etc be different between distros? Why should a russian distro have to be the same as one coming out of the UK? 😛

When two different softwares want to integrate themselves, it is programatically very hard to read, understand and correctly change its partner's configuration file. Think about installing a third-party video driver in XFree86, a new Apache plug-in, etc, and letting this new piece of software do the integration automatically, instead of the sysadmin vi the configuration file, understand and change it in the right way. So basic software integration is a pain today for ISVs (Independent Software Vendors).

This something that groups like Debian have already taken care of for the most part and a registry is only one part of the real fix.

Last time I tried, OpenBSD's packages/ports take care of editting the httpd.conf when installing modules.

A registry would set Linux back 10 years. Bad idea.

I don't think it's quite that bad, but it seems that they're exagerrating the problem. A common API for storing/retrieving configuration settings wouldn't be bad, but it's already been done with GConf.

Which isn't available out of the box on every FOSS OS. And it won't be.

The API would have to be ported to just about everything. FreeBSD, NetBSD, OpenBSD, DragonflyBSD, Solaris, HP-UX, AIX, Linux, etc. It would be a huge undertaking, that wouldn't be all that easy. Especially if it's using a GNU license like this registry project (LGPL).

And on top of that they need each OSS developer's cooperation to use the API which I doubt will happen any time soon.

And those developers would still have to develop the standard and traditional solutions. If they want to support more than Linux anyhow.

 

[Nothinman]

Shouldn't the language, character format, etc be different between distros? Why should a russian distro have to be the same as one coming out of the UK?

That's the point. Right now all those files are in ASCII english and they feel it would be better if they were in the native character set and language, not everyone in the world speaks english, for better or worse.

Last time I tried, OpenBSD's packages/ports take care of editting the httpd.conf when installing modules.

Most Debian packages have a seperate conf file and add an include to the bottom of httpd.conf to avoid possibly bad text edits in the scripts, but the end result is the same.

 

[n0cmonkey]

Originally posted by: Nothinman

Shouldn't the language, character format, etc be different between distros? Why should a russian distro have to be the same as one coming out of the UK?

That's the point. Right now all those files are in ASCII english and they feel it would be better if they were in the native character set and language, not everyone in the world speaks english, for better or worse.

Ahhh, gotcha. Maybe I shouldn't post within x number of hours after I wake up. 😛

Last time I tried, OpenBSD's packages/ports take care of editting the httpd.conf when installing modules.

Most Debian packages have a seperate conf file and add an include to the bottom of httpd.conf to avoid possibly bad text edits in the scripts, but the end result is the same.

Makes sense. I remember OpenBSD just adding the line into the conf file, but it's been a while since I fiddled with it.

 

[Barnaby W. Füi]

People who want radical changes should stop wasting their time trying to implement them on unix-like OSes; they're trying to change the very things that make unix unix.

That's *definitely* not to say that unix does everything perfectly or as well as it could. But it is what it is. If you make drastic changes, it becomes something else.

 

[drag]

/etc isnt' realy flat file space. It's a directory and each program and service can have it's own directory with it's own permissions set up for it. Now there are some exceptions like the /etc/passwd file, but that's a issue by issue basis and these are special purpose and wouldn't realy be served by sticking them in a world readable and world writable database. I don't want to use abratrary permission sceme in a program to protect my password information.

And how is this:
# stem/sw/XFree/current/Module/Load: dbe,extmod,fbdevhw,glx,record,freetype,type1,dri
# system/sw/XFree/current/Files/FontPath: unix/:7100
# system/sw/XFree/current/Files/RgbPath: /usr/X11R6/lib/X11/rgb
# system/sw/XFree/current/ServerLayout/Default/Screen: Screen0
# system/sw/XFree/current/ServerLayout/Default/InputDevice/CorePointer: Mouse0
# system/sw/XFree/current/ServerLayout/Default/InputDevice/CoreKeyboard: Keyboard0
# system/sw/XFree/current/ServerLayout/Default/InputDevice/AlwaysCore: DevInputMice
# system/sw/XFree/current/Screen/Screen0/Device: Videocard0
# system/sw/XFree/current/Screen/Screen0/Monitor: Monitor0
# system/sw/XFree/current/Screen/Screen0/DefaultDepth: 16
# system/sw/XFree/current/Screen/Screen0/Display/Depth: 16
# system/sw/XFree/current/Screen/Screen0/Display/Modes: 1024x768,800x600,640x480
# system/sw/XFree/current/Device/Videocard0/Driver: radeon
# system/sw/XFree/current/Device/Videocard0/BoardName: ATI Radeon Mobility 7500
# system/sw/XFree/current/Device/Videocard0/VendorName: ATI/IBM
# system/sw/XFree/current/InputDevice/Keyboard0/Driver: keyboard
# system/sw/XFree/current/InputDevice/Keyboard0/Option/XkbRules: xfree86
# system/sw/XFree/current/InputDevice/Keyboard0/Option/XkbModel: pc105
# system/sw/XFree/current/InputDevice/Keyboard0/Option/XkbLayout: us_intl
# system/sw/XFree/current/InputDevice/Mouse0/Driver: mouse
# system/sw/XFree/current/InputDevice/Mouse0/Option/Protocol: IMPS/2
# system/sw/XFree/current/InputDevice/Mouse0/Option/Device: /dev/input/mice
# system/sw/XFree/current/InputDevice/Mouse0/Option/ZAxisMapping: 4 5
# system/sw/XFree/current/InputDevice/Mouse0/Option/Emulate3Buttons: no
# system/sw/XFree/current/InputDevice/DevInputMice/Driver: mouse
# system/sw/XFree/current/InputDevice/DevInputMice/Option/Protocol: PS/2
# system/sw/XFree/current/InputDevice/DevInputMice/Option/Device: /dev/psaux
# system/sw/XFree/current/InputDevice/DevInputMice/Option/ZAxisMapping: 4 5
# system/sw/XFree/current/InputDevice/DevInputMice/Option/Emulate3Buttons: no
# system/sw/XFree/current/Monitor/Monitor0/VendorName: IBM T40 monitor
# system/sw/XFree/current/Monitor/Monitor0/ModelName: LCD Panel 1024x768
# system/sw/XFree/current/Monitor/Monitor0/HorizSync/min: 31.5
# system/sw/XFree/current/Monitor/Monitor0/HorizSync/max: 48.5
# system/sw/XFree/current/Monitor/Monitor0/VertRefresh/min: 40
# system/sw/XFree/current/Monitor/Monitor0/VertRefresh/max: 70
# system/sw/XFree/current/Monitor/Monitor0/Option/dpms: 1
# system/sw/XFree/current/Monitor/.Monitor1/VendorName: Samsung
# system/sw/XFree/current/Monitor/.Monitor1/ModelName: SyncMaster 152T
# system/sw/XFree/current/Monitor/.Monitor1/HorizSync/min: 31.5
# system/sw/XFree/current/Monitor/.Monitor1/HorizSync/max: 48.5
# system/sw/XFree/current/Monitor/.Monitor1/VertRefresh/min: 40
# system/sw/XFree/current/Monitor/.Monitor1/VertRefresh/max: 70
# system/sw/XFree/current/Monitor/.Monitor1/Option/dpms: 1
# system/sw/XFree/current/DRI/Group: 0
# system/sw/XFree/current/DRI/Mode: 0666

So much more simplier and elegant then what we already have? Were do I stick the comments in the file so that I can tell people what DRI Mode means?


I don't know about you, but have you ever used Regedit much? Have you ever looked or tried to read a book that documents the Windows registry.

I have, and it's DEFINATELY MUCH MUCH harder then anything I've EVER delt with in Linux.


Plus what are you going to do when a installation program freaks out and injects 30megs of gibberish into the registry? Is it going to take out your OS like it does with Windows? And what is this crap about adding user perferences and crap like that to it?

How do I back up my configuration for Apache? Am I going to have to rely on some GUI tool or Webbased configuration device to parse out my config into a nice neat file for me? Now how am I going to do that when there is 30 megs of crap in the registry and my web based configuraiton won't work and my GUI configuration tool is toast and I need to move my service into a new computer?

No I do not like this at all, it's a very bad idea.


We already have a registry of sorts anyways. It's the /etc directory itself.

If it's the configuration files need more standardization, then standardize them. If each distro has different placement of directories, then make them place them all in the same spots.

What? That would be HARD???

Well then try to convince them to make all their registries to be exactly the same and use exactly the same keypairs. That's a hell of a lot less likely.

Plus their link to the Reiser's comments don't have jack sh!t to do with a registry for Linux. That was pure BS. And I don't see what Reiser was complaining about the passwd file would be solved in any way by a registry.

IN fact It would make the problem worse.

from that website:

Different distributions use to put different software configuration in different places with differente formats. A regular SuSE system administrator, for example, will be lost when asked to work in a Debian or Slackware system. Think about the most primitive example: network configuration parameters. Each distro has its own approach.

Ha. Bullshit.

System adminstrator with half a brain:
"Oh, I am a Suse administrator. I need to administrate a Debian box."
"But I can't find the Proftp configuration files because it is in a slightly different directory"
"Gee, I wish there was a registry for me to use... Oh, what I am not a moron. I will now type:"
locate ftp |grep etc

(the network configuration is worst case scenero, and is solved by spending 30 seconds and googling for online documentation).

This is not rocket science.

The Windows registry was one of the worst things I've ever delt with. Next to that was the AS/400 menu system (thank god that the inventors of Unix were not as retarded as the creators of AS/400 (IBM makes the most pain-in-the-rear operating systems sometimes.).)

I don't want the 3rd worst thing to be the Linux Registry.


I like Gconf for Linux, that is close to a registry, but it's user preferences only and safe.
If it screws up (and it does and it has) all I have to do is rm -rf ~/.gconf and it's automaticly regenerated. I don't want to do the same thing with my system configuration files, though.

 

[Haden]

I don't like the idea of a registry. I like editing my fstab by hand, or my grub.conf.

And you could continue to do so, keys to xml is already done as a proof of concept,
keys to config is simple too (e.g. vim plugin). And don't forget - each key can hold comment.
Think of "standart" config structure: some comments, label name and its value.
e.g.:

# PidFile: The file in which the server should record its process
# identification number when it starts.
PidFile /var/run/apache.pid

Same, but obfuscated, sometimes hard to parse, and doesn't hold to philosophy code once and reuse.

man

For humans, programs (frontends) waste time adapting to new formats, and waste even more supporting them all.

They hold different information, of course their formats are different.

How different?
They hold labels with their values, whenever its "Port 22", or "ServerRoot /etc/apache", grouped or single doesn't matter.
All config files hold are keys, values and comments (only differently named)


Btw, Debian has chopped e.g. exim4 config into many parts - I see it as facing problem (huge, bulky config files), but choosing only temporal solution.

 

[n0cmonkey]

Originally posted by: Haden

I don't like the idea of a registry. I like editing my fstab by hand, or my grub.conf.

And you could continue to do so, keys to xml is already done as a proof of concept,
keys to config is simple too (e.g. vim plugin). And don't forget - each key can hold comment.
Think of "standart" config structure: some comments, label name and its value.
e.g.:

# PidFile: The file in which the server should record its process
# identification number when it starts.
PidFile /var/run/apache.pid

Same, but obfuscated, sometimes hard to parse, and doesn't hold to philosophy code once and reuse.

That's basically how it works now. Without the extra work of creating an API, converting EVERY program over to it, and making people have to relearn 30 years of education.

man

For humans, programs (frontends) waste time adapting to new formats, and waste even more supporting them all.

Exactly. Why add another format with this silly idea?

They hold different information, of course their formats are different.

How different?

It depends on what the configuration file is for. Compare fstab with passwd.

They hold labels with their values, whenever its "Port 22", or "ServerRoot /etc/apache", grouped or single doesn't matter.
All config files hold are keys, values and comments (only differently named)

Ok, and we need another format to handle it correctly?

Btw, Debian has chopped e.g. exim4 config into many parts - I see it as facing problem (huge, bulky config files), but choosing only temporal solution.

And a registry is going to change that how? It's the same configuration, in a different format. Instead of:

Port 80

we get:

port=0x50

or some such non-sensical thing. What does it really change? How does it make anything better?

It lowers security by forcing everyone to relearn everything from the ground up. It does not hold to the traditions of Unix. It requires a heck of a lot of work both with the basic system and the software. The software will then have to support yet ANOTHER format because not everyone will switch to a registry. It's using a GNU license. The LGPL is better than then GPL (freedom wise), but it's still not great.

I think it's neat that someone is working on something like this. Hope they have a good time. It won't become a standard though, thankfully.

 

[Haden]

Plus what are you going to do when a installation program freaks out and injects 30megs of gibberish into the registry?

And what would you do if some program would insert 30megs gibberish into /etc? There aren't few files.

How do I back up my configuration for Apache?

tar czvf bazkup.tar.gz /system/sw/apache or smth.

 

[drag]

They hold different information, of course their formats are different.

How different?
They hold labels with their values, whenever its "Port 22", or "ServerRoot /etc/apache", grouped or single doesn't matter.
All config files hold are keys, values and comments (only differently named)[/quote]


Ya but for each program or service your dealing with each label and each value will be different.

If I set up Icecast it's probably going to use a totally different set of labels, and totally different set of values for each configuration option. And there are possibly hundreds of configuration options for Icecast or Apache. For a entire system your going to be dealing with thousands of configuration options.

How I am going to know what options to add were and what the format of them are? I am going to have to spend as much time learning and memorizing keypairs as I do looking up configuration files formats now. Knowing how ProFTP or Apache sets up their keypairs isn't going to help me at all when I have to relearn how to fix my Xorg configuration or Icecast setup.

 

[n0cmonkey]

Originally posted by: Haden

Plus what are you going to do when a installation program freaks out and injects 30megs of gibberish into the registry?

And what would you do if some program would insert 30megs gibberish into /etc? There aren't few files.

They won't. Most programs don't do configuration on their own and do not have write access to /etc.

How do I back up my configuration for Apache?

tar czvf bazkup.tar.gz /system/sw/apache or smth.

And when the /system filesystem/partition goes cablooey? Or is this another one of those directories that needs to be part of /?

 

[Haden]

Ok, and we need another format to handle it correctly?

No, you don't understand my point: every config file you can find in /etc is collection of keys, values and comments. They can be grouped, as usual if xfree86 config, they can be uncommented etc. etc.

It isn't different format, it is mother of all formats: there isn't a single config (which I can thing of) which would not fit into this philosophy [keys, values, comments].

And no, there is no "lets force hex, or bin" here.

 

[n0cmonkey]

Originally posted by: drag

They hold different information, of course their formats are different.

How different?
They hold labels with their values, whenever its "Port 22", or "ServerRoot /etc/apache", grouped or single doesn't matter.
All config files hold are keys, values and comments (only differently named)

Ya but for each program or service your dealing with each label and each value will be different.

If I set up Icecast it's probably going to use a totally different set of labels, and totally different set of values for each configuration option. And there are possibly hundreds of configuration options for Icecast or Apache. For a entire system your going to be dealing with thousands of configuration options.

How I am going to know what options to add were and what the format of them are? I am going to have to spend as much time learning and memorizing keypairs as I do looking up configuration files formats now. Knowing how ProFTP or Apache sets up their keypairs isn't going to help me at all when I have to relearn how to fix my Xorg configuration or Icecast setup.

I think one of their plans is to get every FOSS developer to work together and standardize on everything. Yes, I kept a straight face when I typed that, but it was hard.

 

[Nothinman]

Btw, Debian has chopped e.g. exim4 config into many parts - I see it as facing problem (huge, bulky config files), but choosing only temporal solution.

They've also chopped up other programs config files and added run-parts type directories for them to make packaging new config files easier, not necessarily because one big config file is difficult to read.

For humans, programs (frontends) waste time adapting to new formats, and waste even more supporting them all.

Yes and this project does nothing more than add 1 more format to the mix. Do you really think this registry would be accepted by companies with commercial unixes like Solaris, Tru64 or HP-UX? Highly doubtfull and because of that anything that supports this registry would also have to support their 'legacy' config file format for everything except Linux which would just add more complexity and work to each project that decides to do that.

Same, but obfuscated, sometimes hard to parse, and doesn't hold to philosophy code once and reuse.

Sure it does, as long as the same library is used to parse the obfuscated config files, the format of the data is irrelevant to the reuse of the code to parse it. And if you think about it, files like /etc/passwd which are considered cryptic are insanely easy to parse because they're simple, just read the line and split using : as a delimiter and you have all your data. For example, 'my ($username, $passwd, $uid, $gid, $real_name, $home_dir, $shell) = split(/:/, $line);' is all it takes in perl to do that.

 

[n0cmonkey]

Originally posted by: Haden

Ok, and we need another format to handle it correctly?

No, you don't understand my point: every config file you can find in /etc is collection of keys, values and comments. They can be grouped, as usual if xfree86 config, they can be uncommented etc. etc.

It isn't different format, it is mother of all formats: there isn't a single config (which I can thing of) which would not fit into this philosophy [keys, values, comments].

And no, there is no "lets force hex, or bin" here.

Of course every config file is pretty much a bunch of fields and values. Maybe I'm misunderstanding something here. I guess I'll have to re-read the registry page, because they talk a bunch of stuff about how things are done now, and you make it out that they just want everything in /system instead of /etc.

 

[drag]

tar czvf bazkup.tar.gz /system/sw/apache or smth.

I don't understand.


So this "registry" isn't going to be a single file stored with all these options ala Windows, but instead be a directory full of configuration files?


And instead of just using the directory system /etc/ your going to use a directory system /system/?

 

[n0cmonkey]

Originally posted by: drag

tar czvf bazkup.tar.gz /system/sw/apache or smth.

I don't understand.


So this "registry" isn't going to be a single file stored with all these options ala Windows, but instead be a directory full of configuration files?


And instead of just using the directory system /etc/ your going to use a directory system /system/?

That's what he makes it sound like. They want a standard config file format and they want to call it a registry. But it isn't a registry, it's just /etc by another name. 😕

re-reading page now.

 

[Haden]

drag has good question,

if you compare XF86Config to httpd.conf, they are different. But, convert them to dired key structure.
Section/EndSection would be droped, as well as </>, in the end they wouldn't be much different by structure, logic is logic of course.

How one would configure new program? Well, currently its take default config, read comments, maybe manual.
Similar approach would be taken here, primitive layer, like my mentioned vim plugin, would shield one from "hundreds of keys" and give standart looking configs if he wishes so.

Hating win registry (should they rename project? 😉) seems impact discussion very much.

 

[Haden]

So this "registry" isn't going to be a single file stored with all these options ala Windows, but instead be a directory full of configuration files?

Nope.
No single point of failure, just like old good /etc but standart, and every program, with virtually no dependencies, can/will have a layer of access to it thrown for free. No more parsing, and no more "should our configs be xml or apache style or?".

 

[n0cmonkey]

3.1. True Facts About Linux Registry
It is much more an agreenment then a piece of software. Relation is 99% to 1%.

Yeah, try getting all of those egos to work together. 😛

It is a simple and consistent API to help software developers programatically store and retrieve global and user-specific configuration parameters.

Great concept.

All key-value pairs are stored in clear-text files.

Kind of like it's done now. But different.

It provides a unique namespace for all values. Anywhere, anytime, any program can preciselly access keys by their names. Security restrictions may obviously apply.

Kind of like it's done now. But different.

It is designed to be secure and lightweight, to let even early boot-stage programs like /sbin/init to use it, instead of /etc/inittab file.

How much more secure is it going to be?

It is designed to be easy to administrate with regular command line tools like cat, vi, cp, ls, ln. Its storage is 100% open.

Like it is now, but different.

It tries to set distribution-independent naming standards to store things like hardware configuration, networking, user's session configuration, system's mime-types, parameters for kernel modules, etc, that are generally stored under /etc.

Are things that different between distros? Ignore networking stuff for the moment. 😉

It requires existing software to be changed to use its API. This will substitute hundreds of configuration-text-file parsing code, into clear Registry's API key-value access methods.

Kind of like it's done now. But different.

It is POSIX compliant. If it doesn't compile and run easily on some POSIX system, it should be easily modified to do so. The "Linux" part of its name is there only for marketing.

Heh, marketing. In freeish software. Go figure.

3.2. Linux Registry Is Not
Is NOT something that accesses SQL/relational databases

Is NOT an OS service that can become unavailable and make system unusable. It is just a library to access files according to a namespace.

Is NOT an alternative to network information systems like LDAP or NIS. These are still required for networked environments.

Is NOT a Webmin-like or other GUI tool to be used by end users.

Is NOT an additional software layer to edit/generate existing configuration files.

Is NOT a "configuration system", because one can't be created by simply writing some code. A configuration system is an ecosystem, and the Registry tries to help build one.

It doesn't know a thing about the semantics of each data it stores.

So basically, it's just a standard configuration file. But different.

Instead of creating some software project, why didn't these guys just get together with all of the software developers out there and bring up the idea of a standard for config files?

 

[n0cmonkey]

user
The current user's keys. Equivalent to the dotfiles in a user's $HOME directory.

Am I the only one confused by why the user's configuration stuff should be moved outside of their home directory? That's the safest and most intuitive location for it.

And the /etc/passwd example I was hoping they would have:

4.3. Key Examples
Here are some valid key names, and their values:

The registry keys of the combined /etc/passwd and /etc/shadow entry for user 'nobody' would look like:

system/users/nobody/uid: 99
system/users/nobody/gid: 99
system/users/nobody/gecos: Nobody
system/users/nobody/home: /
system/users/nobody/shell: /sbin/nologin
system/users/nobody/password: *
system/users/nobody/passwdChangeBefore: 0
system/users/nobody/passwdChangeAfter: 99999
system/users/nobody/passwdWarnBefore: 7
system/users/nobody/passwdDisableAfter:
system/users/nobody/passwdDisabledSince:
system/users/nobody/passwdReserved:

Is this looking overly complicated to anyone else?