Re: Junior Annoying Hacker Task
Thus spake Miguel Mendez [EMAIL PROTECTED]: On Sat, 02 Feb 2002 03:29:50 -0800 Terry Lambert [EMAIL PROTECTED] wrote: Hi Terry et al, Let me know the form you want the hierarchy to take, so you can stick it into the GTK hierarchy thingy; I'll be happy to crank out some quick yacc and lex code to do the parsing of the file into that format for you. A structure definition, with links, and how you want it linked, would be ideal. 8-). I've been thinking about it and I'd like to provide two frontends, a GTK one and a ncurses one, what do you think? This is getting pretty ambitious. I'm not about to say that a procedural interface to rc.conf wouldn't be nice, or that it couldn't be done well, but when it comes down to it, what problem are we trying to solve? Certainly rc.conf supports a lot of options, and a hierarchical arrangement would simplify things. However, most people only need to deal with a small subset of the options, and organization doesn't seem to be a big issue. Of course there's also the possibility that someone could leave out a quotation mark and end up with a non-working system, but that's rare and solvable with simpler tools, as has been discussed. Besides, both Microsoft and the linuxconf people have done far worse than rc.conf---especially Microsoft. Know what to do when a bad update eats a VXD that isn't on the Windows CD? :P [I'm not subscribed to -current, so please CC me any replies if that's where this thread has drifted.] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
Andrew Cowan wrote: However, I have previously thought that a system that used xml files to store application configs (that would then be used to generate valid conf files) would be useful. I was on the verge of doing so the other day. Basically, I wanted to have standard configuration data describing the network, services and service configuration stored in XML and use XSLT to produce which-ever config files you need. You then introduce some inheritance and allow configuration to be overridden for particular hosts, subnets, networks, and/or platforms, and you have a powerful site-wide configuration management tool. You get all the usual benefits from using XML as well; data source, processing and output independence, so the configuration data could be use to automatically generate HTML for helpdesk pages, could be sourced from existing a variety of new or pre-existing data repositories (LDAP, CVS, file system, etc.) and could be processed and edited using a number of standard tools. If only I had not run out of time write it, I'd be happily using this today. Mike. -- Mike Gratton [EMAIL PROTECTED] Every motive escalate. Blatant self-promotion: http://web.vee.net/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Junior Annoying Hacker Task
Hi, I don't know whether the suggested approach is really a good one or not, but as far as implementing some registry-like features in FreeBSD, we have developped something that proves to be useful. The idea was to extend the sysctl mechanism to make it dynamic from the user-land point of view. This was implemented as a kernel module (a simple one too) and a modified sysctl command line. With this mod we can add/remove nodes in the sysctl tree and use it to store information that is needed by many applications. The implementation we have is certainly rough, but it gets the job done and represents a very easy and convenient tool for: - sharing non sensitive bits of information between processes - storing configuration/status data in an easy to use manner - benefit from the tree like presentation of sysctl (building a gui around this should be easy) - don't loose the 'vi' compatibility (sysctl values can be loaded at boot time from a text file) Note that the security model around these 'user-land dynamic sysctl entries' can be improved significantly, but as a proof of concept the mod is useful. Some may argue that storing userland data in the kernel space is Not A Nice Thing(tm) but it certainly makes things a lot easier. Patrick. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
On Tue, Feb 05, 2002 at 01:30:53AM +1030, Mike Gratton wrote: However, I have previously thought that a system that used xml files to store application configs (that would then be used to generate valid conf files) would be useful. I was on the verge of doing so the other day. Basically, I wanted to have standard configuration data describing the network, services and service configuration stored in XML and use XSLT to produce which-ever config files you need. You then introduce some inheritance and allow configuration to be overridden for particular hosts, subnets, networks, and/or platforms, and you have a powerful site-wide configuration management tool. Great minds and all that: http://people.freebsd.org/~nik/xml-servers/ I'm going to try and do a 5 minute 'Work in Progress' on this at BSDCon next week if anyone's interested. Feel free to take that as a starting point. N -- FreeBSD: The Power to Serve http://www.freebsd.org/ (__) FreeBSD Documentation Projecthttp://www.freebsd.org/docproj/\\\'',) \/ \ ^ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- .\._/_) msg34120/pgp0.pgp Description: PGP signature
RE: Junior Annoying Hacker Task
On Mon, 2002-02-04 at 11:03, Patrick Bihan-Faou wrote: Some may argue that storing userland data in the kernel space is Not A Nice Thing(tm) but it certainly makes things a lot easier. Why am I reminded of when terminal type information was bodged into the stty settings as a 2-character code? -- brandon s. allbery [os/2][linux][solaris][japh] [EMAIL PROTECTED] system administrator [WAY too many hats][EMAIL PROTECTED] electrical and computer engineeringKF8NH carnegie mellon university [better check the oblivious first -ke6sls] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
On Saturday 02 February 2002 03:57 pm, Juha Saarinen wrote: On Sat, 2 Feb 2002, Brian T.Schellenberger wrote: No, it's not, because it still maintains a separation between system control (rc.conf) and application control (/var/packges). It's more like config.sys or something . . . Much more than that. The registry also stores dynamic data, such as performance counters. It's also remotable, for centralised management. No, no, I was saying that *rc.conf* was more like config.sys than the registry. The registry is a huge monolithic monstor of an abomination from hell. Not that I don't like it or anything :-) -- Brian T. Schellenberger . . . . . . . [EMAIL PROTECTED] (work) Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal) ME -- http://www.babbleon.org http://www.eff.org -- GOOD GUYS -- http://www.programming-freedom.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
On Sat, 02 Feb 2002 03:29:50 -0800
Terry Lambert [EMAIL PROTECTED] wrote:
Hi Terry et al,
Let me know the form you want the hierarchy to take, so
you can stick it into the GTK hierarchy thingy; I'll be
happy to crank out some quick yacc and lex code to do
the parsing of the file into that format for you. A
structure definition, with links, and how you want it
linked, would be ideal. 8-).
I've been thinking about it and I'd like to provide two frontends, a GTK one and a
ncurses one, what do you think?
Something like:
typedef enum _nodekind {
NK_VALUE, /* Path component */
NK_KEY, /* Key */
[.]
struct node *child;
int intval;
char *strval;
struct wcval *wcval;
} u;
};
It looks fine to me.
Is your idea to manage rc.conf from there or maybe sysctl variables could be added too
(once a working version of the rc.conf thing is made, of course).
Cheers,
--
Miguel Mendez - [EMAIL PROTECTED]
Public Key :: http://energyhq.homeip.net/files/pubkey.txt
EnergyHQ :: http://energyhq.homeip.net
FreeBSD - The power to serve!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
On Sun, 3 Feb 2002 00:38:34 +0800 (MYT) Dinesh Nair [EMAIL PROTECTED] wrote: Hi, times, well, not with the registry paradigm, but some sort of graphical admin tool based on GTK. I'm doing exams this week but may take a go at it after I finish them. why not use something like webmin ? webmin requires a web browser, 'foo' won't :) My idea is that it will work both on console (ncurses) and X (GTK), and because freedom of choice is a good thing. And I don't like webmin at all :-) Cheers, -- Miguel Mendez - [EMAIL PROTECTED] Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://energyhq.homeip.net FreeBSD - The power to serve! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Junior Annoying Hacker Task
How about editing the rc.conf file from the proposed virc program, that would then re-generate the rc.conf file upon saving. Of course the virc would store the underlying configuration in an xml config file.. That should make Kutulu very happy :) I would like to remind viewers that I am just kidding However, I have previously thought that a system that used xml files to store application configs (that would then be used to generate valid conf files) would be useful. It would allow gui tools to be easily designed for system administration. Cheers, Andrew Terry Lambert [EMAIL PROTECTED] types: I guess NIH beats an idea to death, even if the original implementation bears no resemblence to the current one. The problem with the registry is not that it's a single place that tries to control everything. The problem with the registry is that you have to have a large chunk of the system functioning in order to fix things in it should it break - which, from what I've seen, happens all to frequently. Compare this to unix, where all you need is the kernel, init, sh and ed - and sufficiently clever people may be able to do it without init. I offer AIX as an example. IBM decided that all those silly flat text files in Unix was a bad idea and replaced them with object database. They didn't put everything in one big file like Windows does, but grouped them logically, meaning the grouping was unrelated to the flat text files unix admins used to know. Of course, each different db used a different command, with a different syntax, to edit the db. I guess if you're going to make old knowledge useless, you might as well be thorough about it. What this meant in practical terms was that fixing the system required all the db mechanisms to be working, plus either the man pages or menu-driven admin tool to be working in order to fix a broken system. And that was one of the better features of AIX. Juha Saarinen [EMAIL PROTECTED] types: On Sat, 2 Feb 2002, Brian T.Schellenberger wrote: Then again, the registry is the epitome of all that's counter-intuitive, awkward and generally oh-why-does-it-have-to-be-like-this. Maybe it should be ported to FreeBSD? ;- I haven't followed the thread, so apologies if this is repeated. I think having menu-driven front end for editing *.conf files - right now, that would be rc, make, pccard and periodic - isn't such a bad idea. Nothing about the current behavior needs to change. It's no worse than letting people use the sysinstall disk management subsystem rather than fdisk and disklabel. Ideally, it would read all of /etc/defaults/*.conf for a description of each such file. When you chose to edit that file, it would read the contents for the list of variables and what they do - in the comments - along with the default values, then get the current values from the appropriate file in /etc. That means the tool doesn't get out of sync with the files - except for maybe make.conf. It would require reworking the comments in the files in /etc/defaults, and a little more discipline in editing them, but that's not necessarily a bad thing. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Junior Annoying Hacker Task
[Context lost to top posting.] Andrew Cowan [EMAIL PROTECTED] types: How about editing the rc.conf file from the proposed virc program, that would then re-generate the rc.conf file upon saving. Of course the virc would store the underlying configuration in an xml config file.. That should make Kutulu very happy :) I think it should be called viconf, as it should work on rc.conf, make.conf, periodic.conf, and any other .conf files we want. I would like to remind viewers that I am just kidding I didn't take you seriously, except about the name. However, I have previously thought that a system that used xml files to store application configs (that would then be used to generate valid conf files) would be useful. It would allow gui tools to be easily designed for system administration. I don't see how it would make it any easier than using flat text files, unless you're planning on providing a DTD and using generic XML gui editors. Putting data in XML doesn't automatically imbue it with anything, except the ability to use generic XML tools on it. Of course, given line-seperated records with a unique field separator, you can use generic tools on those just as well. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Junior Annoying Hacker Task
SNIP I don't see how it would make it any easier than using flat text files, unless you're planning on providing a DTD and using generic XML gui editors. Putting data in XML doesn't automatically imbue it with anything, except the ability to use generic XML tools on it. Of course, given line-seperated records with a unique field separator, you can use generic tools on those just as well. I was thinking of XML as there would be a huge war in choosing the 'unique field separator' :) XML is somewhat a standard nowdays - even though it is somewhat stupid. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
On Fri, Feb 01, 2002 at 04:26:13PM -0800, Terry Lambert wrote: foo_enable=NO ipfilter_enable=YES firewall_enable=NO natd_enable=NO natd_interface=fxp0 inetd_enable=NO inetd_program=/usr/sbin/inetd foo_enable=YES/NO foo_enable=NO Who is a GTK hacker? Does someone want to write a registry editor program? The point of the program would be to edit the FreeBSD Registry, rc.conf, and make it look just like the Windows Registry in the editor, using _ as the implied path component/terminal component (key) seperator. Then we can all be honest with ourselves that the only difference between it an the Windows Registry is that the Windows registry is accessible/modifiable from kernel mode, and the path component and key names. I would add differences like: the M$ registry is bound to be corrupted, is only accessible by obscure tools, is for the best part not documented In other words why should FreeBSD adopt something like that? -- | / o / /_ _ email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
* Wilko Bulte ([EMAIL PROTECTED]) wrote: On Fri, Feb 01, 2002 at 04:26:13PM -0800, Terry Lambert wrote: Does someone want to write a registry editor program? rc editor.. registry would imply it's going to be used generally, where as it'll be a cold day in hell before anybody lets rc.conf leak out of the rc system. Then we can all be honest with ourselves that the only difference between it an the Windows Registry is that the Windows registry is accessible/modifiable from kernel mode, and the path component and key names. The Windows registry is also extremely deep and complex. If we really want to emulate it, we'll also need to store where every dll is on the system behind sha1 hashes and then dump 99% of them in /lib and the other 1% in random locations on the filesystem, after renaming them to less obscure names (libsablot.so - sbtxmlpr80.dll, libperl.so - prllng5.dll, etc) After doing that, we'll have to work hard to make every application and tool on the system move their configs to it, leaving us with a nice and clean /etc. People who want a text file can have a 30MB text file that's slow but easy to edit, and everyone else can use a dbm. I don't see how what we have now even remotely resembles that. We don't even have a proper hierachy, and even if we did, hierachies are not only limited to the Windows registry. Maybe some sort of hierachy would be good.. /etc/rc.conf/services # sendmail, bind etc /etc/rc.conf/security # firewall, secure levels /etc/rc.conf/system # library paths and other low level tweakables I would add differences like: the M$ registry is bound to be corrupted, I've only come across a handful. Equally I've come across Linux systems where things similar to the registry (in this case, the Debian package list, erk) were corrupted. is only accessible by obscure tools, The system calls to access it seem to be quite well known :) is for the best part not documented Just because nobody's seen any, doesn't mean it's not documented. I'm sure it's there somewhere, nested deep on Microsoft's website, with such obscure search engine keywords attached that I can't even begin to think what they might be. In other words why should FreeBSD adopt something like that? Irony value :) -- Thomas 'Freaky' Hurst - [EMAIL PROTECTED] - http://www.aagh.net/ - I wouldn't recommend sex, drugs or insanity for everyone, but they've always worked for me. -- Hunter S. Thompson To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
On Fri, Feb 01, 2002 at 04:26:13PM -0800, Terry Lambert wrote: Hi Terry, Who is a GTK hacker? I've done some GTK programs in the past. Does someone want to write a registry editor program? The point of the program would be to edit the FreeBSD Registry, rc.conf, and make it look just like the Windows Registry in the editor, using _ as the implied path component/terminal component (key) seperator. Then we can all be honest with ourselves that the only difference between it an the Windows Registry is that the Windows registry is accessible/modifiable from kernel mode, and the path component and key names. Are you really serious about this? :) I've thought about that many times, well, not with the registry paradigm, but some sort of graphical admin tool based on GTK. I'm doing exams this week but may take a go at it after I finish them. Cheers, -- Miguel Mendez - [EMAIL PROTECTED] Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://energyhq.homeip.net FreeBSD - The power to serve! msg34032/pgp0.pgp Description: PGP signature
Re: Junior Annoying Hacker Task
Matt Heckaman wrote: Yeah, but we've also got a file edited by root and root alone, why would root be trying to add all kinds of code in it? I think rc.conf will be failing as it is if people add certain code in it, what do we lose? The same reason we check the syntax of the password entries, rather than letting root and root alone put bogus crap into the file. 8-). This is one of the reasons I prefer procedural to data interfaces, in any case (proc size mismatch being another). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
Wilko Bulte wrote: I would add differences like: the M$ registry is bound to be corrupted, is only accessible by obscure tools, is for the best part not documented In other words why should FreeBSD adopt something like that? rc.conf is a registry in all but tools. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
Miguel Mendez wrote:
Are you really serious about this? :) I've thought about that many
times, well, not with the registry paradigm, but some sort of graphical
admin tool based on GTK. I'm doing exams this week but may take a go at
it after I finish them.
Let me know the form you want the hierarchy to take, so
you can stick it into the GTK hierarchy thingy; I'll be
happy to crank out some quick yacc and lex code to do
the parsing of the file into that format for you. A
structure definition, with links, and how you want it
linked, would be ideal. 8-).
Something like:
typedef enum _nodekind {
NK_VALUE, /* Path component */
NK_KEY, /* Key */
NK_DATA_INT,/* 32 bit integer */
NK_DATA_STRING, /* String */
NK_DATA_BINARY /* Word count prefix bytestream */
} nodekind_t;
struct wcval {
int16_t count; /* howw many bytes in bytes */
char bytes[ 1]; /* actually longer */
};
struct node {
struct node *parent;
struct node *sibling;
nodekind_t kind;
union {
struct node *child;
int intval;
char *strval;
struct wcval *wcval;
} u;
};
But I could arrange something else, if it would be more useful
for it to be some other data structure. ;-).
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
On Sat, Feb 02, 2002 at 03:29:50AM -0800, Terry Lambert wrote: Miguel Mendez wrote: Are you really serious about this? :) I've thought about that many times, well, not with the registry paradigm, but some sort of graphical admin tool based on GTK. I'm doing exams this week but may take a go at it after I finish them. Let me know the form you want the hierarchy to take, so you can stick it into the GTK hierarchy thingy; Just go and port NetInfo from Apple's Darwin. N -- FreeBSD: The Power to Serve http://www.freebsd.org/ (__) FreeBSD Documentation Projecthttp://www.freebsd.org/docproj/\\\'',) \/ \ ^ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- .\._/_) msg34036/pgp0.pgp Description: PGP signature
Re: Junior Annoying Hacker Task
From: Brian T.Schellenberger [EMAIL PROTECTED] Sent: Friday, February 01, 2002 7:31 PM I don't see that at all--the most distinctive characteristic to me of the Microsoft Windows Registry is that it tries to be a *single* place where *all* configuration information--both system and application--is written. If you ask Microsoft I'm pretty sure they'd tell you that's it's prime advantage and I claim that it's prime drawback. Either way, that's what most Actually, if you ask them *now* they will tell you it's a pain in the ass. Which is why they are moving away from the registry with .NET to application-specific manifests. Much like MDI, this is another great Microsoft 'innovation' that everyone copied until it became a de-facto standard... just in time for Micrsoft to declare it a failure. :x (Waiting for someone to suggest XML manifests for FreeBSD, and cringing). --K To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
Just go and port NetInfo from Apple's Darwin. I assume from this that there isnt currently a FreeBSD netinfo implementation then unfortunately ? So why is it mentioned in the ntpd man page ? -pcf. [someone been nicking man pages from NeXT system ? :-)] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
Nik Clayton heeft op zaterdag 2 februari 2002 om 13:37 het volgende geschreven: Let me know the form you want the hierarchy to take, so you can stick it into the GTK hierarchy thingy; Just go and port NetInfo from Apple's Darwin. Now that is a cool idea. Netinfo has been around for quite a while in NeXT machines. It would be really cool if I could setup a Netinfo root on a FreeBSD box to manage my Mac OS X running macs. Actually, I was already wondering why there isn't such a thing for the free *nix like operating systems... Oh, I am not volunteering, it's way beyond my capabilities. Cheers, Emiel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
Don't try to persuade somebody to accept Microsoft concept, they have never played Microsoft Systems, so they really don't know what you are talking about, I personally like the Microsoft's Registry idea, Microsoft is not always bad, but I never try to force somebody to accept the idea, it wastes time. if UNIX or FreeBSD are doing Registry, It must not be FreeBSD or UNIX, I never think UNIX's system admin will work in the way Windows admin are doing. leave Vi, UNIX is not UNIX, FreeBSD is not FreeBSD. Regards, - Original Message - From: Terry Lambert [EMAIL PROTECTED] To: Brian T.Schellenberger [EMAIL PROTECTED] Cc: Paul Fardy [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, February 02, 2002 9:38 AM Subject: Re: Junior Annoying Hacker Task Brian T.Schellenberger wrote: Does someone want to write a registry editor program? Yuch. Why? Clearly, you are not a Junior Annoying Hacker. The point of the program would be to edit the FreeBSD Registry, rc.conf, and make it look just like the Windows Registry in the editor, using _ as the implied path component/terminal component (key) seperator. You are surely insane. Or trying to make a point which isn't true, which is pretty similar. OK, say we view it as read only, except for the editor (note the editor might be vi, so you can't complain 8-)). How is path-to-file + path-to-key-in-file any different than absolute-path-to-key? The only thing that seems different is the implied component seperator at the file/file-content boundary, and the translation of the _ into the file space component seperator, and back. It's all just a matter of represntational geometry for the same information, isn't it? No, there's are enormous differences: - There's a well-known plain-text file so it can be readily backed up and restored. regedit Registry Export Registry File... backupCR regedit Registry Import Registry File... backupCR - There is not a single point of failure for all progams; it only controls basic system functions and services, it does not control applications, so if it fails, your applications aren't all screwed up, and if your applications screw up terribly they can't corrupt your basic system. firewall_enable=NO 8-) 8-). Indeed, the lack of an API to *write* to /etc/rc.conf is one of it's greatest strengths: It is far less vulnerable to major corruption if things go nutty. vi? sed? any text editor? The lack of constraints on how one may interact with the rc.conf is one of its main weaknesses. A single missing quotation mark will result in an inaccessible system, if you don't have console access, and one that must be repaired, if you do. There's not even a virc equivalent to vipw, that can do a consistency check on the file to make sure it's sourceable by a shell script, before permitting the edits to replace the valid contents, and keep a backup of the previous file for you. Alternately, we can just call a spade a spade, and admit that what we have is a flat file registry, which pretends to be hierarchical by using _ as a hierachy delimiter for component seperation. Actually, this is a lot like the Manx subdirectory support in the shell program that came with the developement environment, and used topdir/subdir/finaldir as the name of the directory, and simply hid the names of all but the last component. 8-). -- Terry _ Do You Yahoo!? µÇ¼Ãâ·ÑÑÅ»¢µçÓÊ! http://mail.yahoo.com.cn font color=#FFÎÞÁÄ£¿ÓôÃÆ£¿¸ßÐË£¿Ã»ÀíÓÉ£¿¶¼À´ÁÄÌì°É£¡/font¡ª¡ª ÑÅ»¢È«ÐÂÁÄÌìÊÒ! http://cn.chat.yahoo.com/c/roomlist.html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
On Sat, 2002-02-02 at 05:59, Thomas Hurst wrote: Maybe some sort of hierachy would be good.. /etc/rc.conf/services # sendmail, bind etc /etc/rc.conf/security # firewall, secure levels /etc/rc.conf/system # library paths and other low level tweakables SuSE Linux does this (/etc/rc.config for system-wide entries, /etc/rc.config.d/* for specific subsystems). It works fairly well aside from having to run a program to propagate entries. (Although that actually is something of a feature, since there's almost always an entry to tell SuSEconfig to leave the real files alone instead of propagating, so you can run things the old way if you want or if you can't DTRT using the rc.config entries.) Also, I think they borrowed this setup from DU / OSF/1. -- brandon s. allbery [os/2][linux][solaris][japh] [EMAIL PROTECTED] system administrator [WAY too many hats][EMAIL PROTECTED] electrical and computer engineeringKF8NH carnegie mellon university [better check the oblivious first -ke6sls] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
On Sat, 2002-02-02 at 08:52, Emiel Kollof wrote: Oh, I am not volunteering, it's way beyond my capabilities. Hm, Darwin is (userspace-wise) mostly FreeBSD 3.x, isn't it? I wouldn't expect porting its NetInfo implementation to be particularly difficult. -- brandon s. allbery [os/2][linux][solaris][japh] [EMAIL PROTECTED] system administrator [WAY too many hats][EMAIL PROTECTED] electrical and computer engineeringKF8NH carnegie mellon university [better check the oblivious first -ke6sls] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
Brandon S. Allbery KF8NH heeft op zaterdag 2 februari 2002 om 16:48 het volgende geschreven: On Sat, 2002-02-02 at 08:52, Emiel Kollof wrote: Oh, I am not volunteering, it's way beyond my capabilities. Hm, Darwin is (userspace-wise) mostly FreeBSD 3.x, isn't it? I wouldn't expect porting its NetInfo implementation to be particularly difficult. AFAIK, Netinfo on Mac OS X is implemented deep. That is, it overrules standard libc behaviour (like the resolver, fstab and other things), Yes it's userspace jim, but not as we know it :) But it's definitely beyond my sphere of control. Cheers, Emiel (who knows when he's overclassed ;) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
On Sat, 2 Feb 2002, Miguel Mendez wrote: times, well, not with the registry paradigm, but some sort of graphical admin tool based on GTK. I'm doing exams this week but may take a go at it after I finish them. why not use something like webmin ? Regards, /\_/\ All dogs go to heaven. [EMAIL PROTECTED](0 0)http://www.alphaque.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo The opinions here in no way reflect the opinions of my $a $b. | | done; done | +=+ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
AFAIK, Netinfo on Mac OS X is implemented deep. That is, it overrules standard libc behaviour (like the resolver, fstab and other things), Yes it's userspace jim, but not as we know it :) This was certainly true on NeXT's - you needed special versions of most programs (e.g. sendmail, bind, login etc...) that were netinfo aware too. If its going to be done it needs doing very thoroughly and carefully as it replaces more of the /etc files with netinfo equivalents. On the other doesnt YP do somethign similar ? (I've never had to use YP, thought I have been on the receiving end of some of the consequences). But it's definitely beyond my sphere of control. Possibly not a job for the fainthearted - but its an interesting idea. I hadnt realised the source to netinfo was now open sourced with Darwin. -pcf. [suddenly quite entheused about this idea] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
On Saturday 02 February 2002 06:15 am, Terry Lambert wrote: Wilko Bulte wrote: I would add differences like: the M$ registry is bound to be corrupted, is only accessible by obscure tools, is for the best part not documented In other words why should FreeBSD adopt something like that? rc.conf is a registry in all but tools. 8-). No, it's not, because it still maintains a separation between system control (rc.conf) and application control (/var/packges). It's more like config.sys or something . . . -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message -- Brian T. Schellenberger . . . . . . . [EMAIL PROTECTED] (work) Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal) ME -- http://www.babbleon.org http://www.eff.org -- GOOD GUYS -- http://www.programming-freedom.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
On Sat, 2 Feb 2002, Brian T.Schellenberger wrote: No, it's not, because it still maintains a separation between system control (rc.conf) and application control (/var/packges). It's more like config.sys or something . . . Much more than that. The registry also stores dynamic data, such as performance counters. It's also remotable, for centralised management. -- Juha Take off every sig! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
On Sat, 2002-02-02 at 14:50, Pete French wrote: AFAIK, Netinfo on Mac OS X is implemented deep. That is, it overrules standard libc behaviour (like the resolver, fstab and other things), Yes it's userspace jim, but not as we know it :) This was certainly true on NeXT's - you needed special versions of most programs (e.g. sendmail, bind, login etc...) that were netinfo aware too. If its going to be done it needs doing very thoroughly and carefully as it replaces more of the /etc files with netinfo equivalents. On the other doesnt YP do somethign similar ? (I've never had to use YP, thought I have been on the receiving end of some of the consequences). And I, somehow, had failed to notice that there's no NSS on FreeBSD. *smacks self on head* Not quite so simple after all, I guess -- brandon s. allbery [os/2][linux][solaris][japh] [EMAIL PROTECTED] system administrator [WAY too many hats][EMAIL PROTECTED] electrical and computer engineeringKF8NH carnegie mellon university [better check the oblivious first -ke6sls] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
And I, somehow, had failed to notice that there's no NSS on FreeBSD. *smacks self on head* Not quite so simple after all, I guess Is this NSS as in the Mozilla crypt stuff ? If so then what does it have to do with netinfo - or is OSX netinfo different to normal netinfo ? [did they break yet another thing ? :-(] BTW, this discussion should probably not be taking place on as many lists as it currently is I suspect. Wheres most appropiate for it ? -pcf. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
Brian T.Schellenberger wrote: No, it's not, because it still maintains a separation between system control (rc.conf) and application control (/var/packges). It's more like config.sys or something . . . Oh, ya got me! Oh! Oh! Yeah... config.sys... MUCH better... 8-) 8-). ...actually, I'd point at the sendmail and natd and other programs that can be replaced, and should probably be installer's choice, rather than being named by application name in rc.conf. You'd have a better argument if these things were named by function, rather than by program name. I think, also, that if you look at Windows XP, you'll see that the per application data has been seperated into a per application configuration space, to keep it from breaking anything. That's more like a .Xdefaults. I guess NIH beats an idea to death, even if the original implementation bears no resemblence to the current one. 8-p -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
Juha Saarinen wrote: No, it's not, because it still maintains a separation between system control (rc.conf) and application control (/var/packges). It's more like config.sys or something . . . Much more than that. The registry also stores dynamic data, such as performance counters. It's also remotable, for centralised management. I'm pretty sure the article It's was referring to rc.conf. FreeBSD's rc.conf can't store dynamic data, and it can't be centrally managed, since there's no programmatic API to it. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
Brandon S. Allbery KF8NH wrote: And I, somehow, had failed to notice that there's no NSS on FreeBSD. *smacks self on head* Not quite so simple after all, I guess There are NSS patches for FreeBSD; check the PR database; they just haven't been integrated. The PR database is like the bugfix motel... 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
Pete French wrote: Is this NSS as in the Mozilla crypt stuff ? If so then what does it have to do with netinfo - or is OSX netinfo different to normal netinfo ? [did they break yet another thing ? :-(] NSS = Name Service Switch GNU LIBC has a nice introductory document: http://www.gnu.org/manual/glibc-2.2.3/html_chapter/libc_28.html -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
On Sat, 2 Feb 2002, Brian T.Schellenberger wrote: No, no, I was saying that *rc.conf* was more like config.sys than the registry. I see. Sorry for the misunderstanding. Then again, the registry is the epitome of all that's counter-intuitive, awkward and generally oh-why-does-it-have-to-be-like-this. Maybe it should be ported to FreeBSD? ;- -- Juha Take off every sig! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
Terry Lambert [EMAIL PROTECTED] types: I guess NIH beats an idea to death, even if the original implementation bears no resemblence to the current one. The problem with the registry is not that it's a single place that tries to control everything. The problem with the registry is that you have to have a large chunk of the system functioning in order to fix things in it should it break - which, from what I've seen, happens all to frequently. Compare this to unix, where all you need is the kernel, init, sh and ed - and sufficiently clever people may be able to do it without init. I offer AIX as an example. IBM decided that all those silly flat text files in Unix was a bad idea and replaced them with object database. They didn't put everything in one big file like Windows does, but grouped them logically, meaning the grouping was unrelated to the flat text files unix admins used to know. Of course, each different db used a different command, with a different syntax, to edit the db. I guess if you're going to make old knowledge useless, you might as well be thorough about it. What this meant in practical terms was that fixing the system required all the db mechanisms to be working, plus either the man pages or menu-driven admin tool to be working in order to fix a broken system. And that was one of the better features of AIX. Juha Saarinen [EMAIL PROTECTED] types: On Sat, 2 Feb 2002, Brian T.Schellenberger wrote: Then again, the registry is the epitome of all that's counter-intuitive, awkward and generally oh-why-does-it-have-to-be-like-this. Maybe it should be ported to FreeBSD? ;- I haven't followed the thread, so apologies if this is repeated. I think having menu-driven front end for editing *.conf files - right now, that would be rc, make, pccard and periodic - isn't such a bad idea. Nothing about the current behavior needs to change. It's no worse than letting people use the sysinstall disk management subsystem rather than fdisk and disklabel. Ideally, it would read all of /etc/defaults/*.conf for a description of each such file. When you chose to edit that file, it would read the contents for the list of variables and what they do - in the comments - along with the default values, then get the current values from the appropriate file in /etc. That means the tool doesn't get out of sync with the files - except for maybe make.conf. It would require reworking the comments in the files in /etc/defaults, and a little more discipline in editing them, but that's not necessarily a bad thing. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Junior Annoying Hacker Task
foo_enable=NO ipfilter_enable=YES firewall_enable=NO natd_enable=NO natd_interface=fxp0 inetd_enable=NO inetd_program=/usr/sbin/inetd foo_enable=YES/NO foo_enable=NO Who is a GTK hacker? Does someone want to write a registry editor program? The point of the program would be to edit the FreeBSD Registry, rc.conf, and make it look just like the Windows Registry in the editor, using _ as the implied path component/terminal component (key) seperator. Then we can all be honest with ourselves that the only difference between it an the Windows Registry is that the Windows registry is accessible/modifiable from kernel mode, and the path component and key names. You can start with: My Computer\HKEY_LOCAL_MACHINE\natd NameData --- - enable NO interface fxp0 My Computer\HKEY_LOCAL_MACHINE\inetd NameData --- - enable NO program /usr/sbin/inetd etc. If you want to get ambitious: o Make HKEY_LOCAL_MACHINE an alias for your node name, and include your node name in the list. o Call it localhost, if you are feeling too guilty about calling it HKEY_LOCAL_MACHINE. o Make the tool operate on node names other than localhost, so you can do remote administration of configuration files on a cluster of FreeBSD boxes o Add more subkeys; perhaps it should not be just My Computer\localhost\inetd but My Computer\localhost\rc.conf\inetd letting you fold in the other files, like the inetd.conf, into registry handlers, e.g.: My Computer\localhost\inetd.conf\telnet enable NO sockettype stream protocoltcp waitNO userroot program /usr/libexec/telnetd etc.. o Support sysctls in the HKEY_DYN_DATA and HKEY_CURRENT_CONFIG sections (for those that can go into loader.rc). Sure, people would be annoyed to find out that they had been moving towards an idea that Microsoft had developed, but wouldn't this be a fun tweak to people's tails? 8-) 8-) 8-) -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
On Fri, Feb 01, 2002 at 04:26:13PM -0800, Terry Lambert wrote: Who is a GTK hacker? Does someone want to write a registry editor program? The point of the program would be to edit the FreeBSD Registry, rc.conf, and make it look just like the Windows Registry in the editor, using _ as the implied path component/terminal component (key) seperator. Then we can all be honest with ourselves that the only difference between it an the Windows Registry is that the Windows registry is accessible/modifiable from kernel mode, and the path component and key names. You can start with: My Computer\HKEY_LOCAL_MACHINE\natd NameData --- - enable NO interface fxp0 My Computer\HKEY_LOCAL_MACHINE\inetd NameData --- - enable NO program /usr/sbin/inetd etc. If you want to get ambitious: o Make HKEY_LOCAL_MACHINE an alias for your node name, and include your node name in the list. o Call it localhost, if you are feeling too guilty about calling it HKEY_LOCAL_MACHINE. o Make the tool operate on node names other than localhost, so you can do remote administration of configuration files on a cluster of FreeBSD boxes o Add more subkeys; perhaps it should not be just My Computer\localhost\inetd but My Computer\localhost\rc.conf\inetd letting you fold in the other files, like the inetd.conf, into registry handlers, e.g.: My Computer\localhost\inetd.conf\telnet enable NO sockettype stream protocoltcp waitNO userroot program /usr/libexec/telnetd etc.. o Support sysctls in the HKEY_DYN_DATA and HKEY_CURRENT_CONFIG sections (for those that can go into loader.rc). This last point is neat, especially if whoever is doing it could setup something with the doc team and actually get to actively documenting, as things progress, what each sysctl does and affects. Sure, people would be annoyed to find out that they had been moving towards an idea that Microsoft had developed, but wouldn't this be a fun tweak to people's tails? 8-) 8-) 8-) -- Terry -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
On Friday 01 February 2002 07:26 pm, Terry Lambert wrote: foo_enable=NO ipfilter_enable=YES firewall_enable=NO natd_enable=NO natd_interface=fxp0 inetd_enable=NO inetd_program=/usr/sbin/inetd foo_enable=YES/NO foo_enable=NO Who is a GTK hacker? Does someone want to write a registry editor program? Yuch. Why? The point of the program would be to edit the FreeBSD Registry, rc.conf, and make it look just like the Windows Registry in the editor, using _ as the implied path component/terminal component (key) seperator. You are surely insane. Or trying to make a point which isn't true, which is pretty similar. Then we can all be honest with ourselves that the only difference between it an the Windows Registry is that the Windows registry is accessible/modifiable from kernel mode, and the path component and key names. No, there's are enormous differences: - There's a well-known plain-text file so it can be readily backed up and restored. - There is not a single point of failure for all progams; it only controls basic system functions and services, it does not control applications, so if it fails, your applications aren't all screwed up, and if your applications screw up terribly they can't corrupt your basic system. Indeed, the lack of an API to *write* to /etc/rc.conf is one of it's greatest strengths: It is far less vulnerable to major corruption if things go nutty. You can start with: My Computer\HKEY_LOCAL_MACHINE\natd NameData --- - enable NO interface fxp0 My Computer\HKEY_LOCAL_MACHINE\inetd NameData --- - enable NO program /usr/sbin/inetd etc. If you want to get ambitious: o Make HKEY_LOCAL_MACHINE an alias for your node name, and include your node name in the list. o Call it localhost, if you are feeling too guilty about calling it HKEY_LOCAL_MACHINE. o Make the tool operate on node names other than localhost, so you can do remote administration of configuration files on a cluster of FreeBSD boxes o Add more subkeys; perhaps it should not be just My Computer\localhost\inetd but My Computer\localhost\rc.conf\inetd letting you fold in the other files, like the inetd.conf, into registry handlers, e.g.: My Computer\localhost\inetd.conf\telnet enable NO sockettype stream protocoltcp waitNO userroot program /usr/libexec/telnetd etc.. o Support sysctls in the HKEY_DYN_DATA and HKEY_CURRENT_CONFIG sections (for those that can go into loader.rc). Sure, people would be annoyed to find out that they had been moving towards an idea that Microsoft had developed, but wouldn't this be a fun tweak to people's tails? 8-) 8-) 8-) -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message -- Brian T. Schellenberger . . . . . . . [EMAIL PROTECTED] (work) Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal) ME -- http://www.babbleon.org http://www.eff.org -- GOOD GUYS -- http://www.programming-freedom.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
Brian T.Schellenberger wrote: Does someone want to write a registry editor program? Yuch. Why? Clearly, you are not a Junior Annoying Hacker. The point of the program would be to edit the FreeBSD Registry, rc.conf, and make it look just like the Windows Registry in the editor, using _ as the implied path component/terminal component (key) seperator. You are surely insane. Or trying to make a point which isn't true, which is pretty similar. OK, say we view it as read only, except for the editor (note the editor might be vi, so you can't complain 8-)). How is path-to-file + path-to-key-in-file any different than absolute-path-to-key? The only thing that seems different is the implied component seperator at the file/file-content boundary, and the translation of the _ into the file space component seperator, and back. It's all just a matter of represntational geometry for the same information, isn't it? No, there's are enormous differences: - There's a well-known plain-text file so it can be readily backed up and restored. regedit Registry Export Registry File... backupCR regedit Registry Import Registry File... backupCR - There is not a single point of failure for all progams; it only controls basic system functions and services, it does not control applications, so if it fails, your applications aren't all screwed up, and if your applications screw up terribly they can't corrupt your basic system. firewall_enable=NO 8-) 8-). Indeed, the lack of an API to *write* to /etc/rc.conf is one of it's greatest strengths: It is far less vulnerable to major corruption if things go nutty. vi? sed? any text editor? The lack of constraints on how one may interact with the rc.conf is one of its main weaknesses. A single missing quotation mark will result in an inaccessible system, if you don't have console access, and one that must be repaired, if you do. There's not even a virc equivalent to vipw, that can do a consistency check on the file to make sure it's sourceable by a shell script, before permitting the edits to replace the valid contents, and keep a backup of the previous file for you. Alternately, we can just call a spade a spade, and admit that what we have is a flat file registry, which pretends to be hierarchical by using _ as a hierachy delimiter for component seperation. Actually, this is a lot like the Manx subdirectory support in the shell program that came with the developement environment, and used topdir/subdir/finaldir as the name of the directory, and simply hid the names of all but the last component. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
On Fri, 1 Feb 2002, Terry Lambert wrote: ... : There's not even a virc equivalent to vipw, that can do a : consistency check on the file to make sure it's sourceable by a shell : script, before permitting the edits to replace the valid contents, and : keep a backup of the previous file for you. Out of this entire thread, something I like! This would be a great idea. * Matt Heckaman - mailto:[EMAIL PROTECTED] http://www.lucida.ca/gpg * * GPG fingerprint - 53CA 8320 C8F6 32ED 9DDF 036E 3171 C093 4AD3 1364 * The Universe is run by the complex interweaving of three elements: energy, matter, and enlightened self-interest. -- G'Kar, Survivors To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
Matt Heckaman wrote: On Fri, 1 Feb 2002, Terry Lambert wrote: : There's not even a virc equivalent to vipw, that can do a : consistency check on the file to make sure it's sourceable by a shell : script, before permitting the edits to replace the valid contents, and : keep a backup of the previous file for you. Out of this entire thread, something I like! This would be a great idea. Determining source-ability by sourcing is dangerous. You would need to do a chroot, or run it as a non-priviledged user, for the purposes of testing, and you would not be able to see some side effects, if the file contained code, even then. Also, people use vipw because if you don't, the database doesn't get rebuilt. There's no corresponding force to make them use it for virc. All that aside, I'll admit that it would be better than what's there. But of course, that's more of a Junior Hacker than a Junior Annoying Hacker task, and, really, what we are trying to do here is raise up someone to compete with Albert for number of complaints. 8-) 8-o 8-O }B^). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
On Friday 01 February 2002 08:38 pm, Terry Lambert wrote: Brian T.Schellenberger wrote: - There is not a single point of failure for all progams; it only controls basic system functions and services, it does not control applications, so if it fails, your applications aren't all screwed up, and if your applications screw up terribly they can't corrupt your basic system. firewall_enable=NO I wouldn't think of a firewall as an application program. I can be certain that installing or corrupting or otherwise screwing up my text editor, my image-editing program, by CD-management program, my financial program, my DVD-viewing program, my newsreader, or my browser won't break my firewall. That's the big drawback of the stupid registry idea. Indeed, the lack of an API to *write* to /etc/rc.conf is one of it's greatest strengths: It is far less vulnerable to major corruption if things go nutty. vi? sed? any text editor? Yes, but application programs aren't writing to it. You only write to it when you set down to do it. So vi acts like regedit, except that it's much easier to find things manipulate since you have the same interface to that file that you have to everything else. (For example, Linux maintains kernel options in much this same way, but it's *much* easier to just with an editable (commented) kernel config file; that's a big part of the reason I went back to FreeBSD. The lack of constraints on how one may interact with the rc.conf is one of its main weaknesses. A single missing quotation mark will result in an inaccessible system, if you don't have console access, and one that must be repaired, if you do. There's not even a virc equivalent to vipw, that can do a consistency check on the file to make sure it's sourceable by a shell script, before permitting the edits to replace the valid contents, and keep a backup of the previous file for you. I've never so messed myself up, but I can see where that would be a problem. *This* is a good idea, actually. Alternately, we can just call a spade a spade, and admit that what we have is a flat file registry, which pretends to be hierarchical by using _ as a hierachy delimiter for component seperation. I don't see that at all--the most distinctive characteristic to me of the Microsoft Windows Registry is that it tries to be a *single* place where *all* configuration information--both system and application--is written. If you ask Microsoft I'm pretty sure they'd tell you that's it's prime advantage and I claim that it's prime drawback. Either way, that's what most distinguishes it. Actually, this is a lot like the Manx subdirectory support in the shell program that came with the developement environment, and used topdir/subdir/finaldir as the name of the directory, and simply hid the names of all but the last component. 8-). Building this information into a directory hierarchy sounds clever but gives me nightmares in recalling the startup / daemon control in Linux (using the ATT scheme, I believe)--which sounds like a good idea in theory but I always found was an absolute nightmare in practice. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message -- Brian T. Schellenberger . . . . . . . [EMAIL PROTECTED] (work) Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal) ME -- http://www.babbleon.org http://www.eff.org -- GOOD GUYS -- http://www.programming-freedom.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 1 Feb 2002, Terry Lambert wrote: ... : Determining source-ability by sourcing is dangerous. Well, you said make sure it's sourcable -- not source it :) : You would need to do a chroot, or run it as a non-priviledged user, : for the purposes of testing, and you would not be able to see some side : effects, if the file contained code, even then. Yeah, but we've also got a file edited by root and root alone, why would root be trying to add all kinds of code in it? I think rc.conf will be failing as it is if people add certain code in it, what do we lose? : Also, people use vipw because if you don't, the database doesn't get : rebuilt. There's no corresponding force to make them use it for virc. You can rebuild the database manually *ducks* -- I know what you're saying though, and I've used things similar to vipw for other daemon config files that had no databases simply for the safety of checking syntax. : All that aside, I'll admit that it would be better than what's there. Yep :) : But of course, that's more of a Junior Hacker than a Junior Annoying : Hacker task, and, really, what we are trying to do here is raise up : someone to compete with Albert for number of complaints. 8-) 8-o 8-O : }B^). :) * Matt Heckaman - mailto:[EMAIL PROTECTED] http://www.lucida.ca/gpg * * GPG fingerprint - 46D8 5C3B 5499 1D14 F01C 2ADD D1B9 6165 9E16 F8E4 * The Universe is run by the complex interweaving of three elements: energy, matter, and enlightened self-interest. -- G'Kar, Survivors -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (FreeBSD) Comment: http://www.lucida.ca/gpg/ iD8DBQE8W55K0blhZZ4W+OQRAjqLAKCeMIHPY5g6jhxDKCp42PcDJThmzwCgrpUf NXYHCrKEUqX70qyYFdLESq0= =2VH0 -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
