RE: Junior Annoying Hacker Task

[Brandon S. Allbery]

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

[Nik Clayton]

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

[Patrick Bihan-Faou]

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

[Mike Gratton]

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: 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Junior Annoying Hacker Task

[David Schultz]

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]

> 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 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

[Mike Meyer]

[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 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.

  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

[Andrew Cowan]

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  :)



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 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

[Miguel Mendez]

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

[Miguel Mendez]

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

[Brian T . Schellenberger]

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

[Mike Meyer]

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.

  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

[Juha Saarinen]

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]

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

[Terry Lambert]

"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

[Terry Lambert]

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

[Terry Lambert]

"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

[Pete French]

> 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

[Brandon S. Allbery]

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

[Juha Saarinen]

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

[Brian T . Schellenberger]

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

[Pete French]

> 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

[Dinesh Nair]

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

[Emiel Kollof]

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

[Brandon S. Allbery]

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]

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

[Yifeng Xu]

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...
> backup
> 
> regedit
> Registry
> Import Registry File...
> backup
> 
> > - 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

ÎÞÁÄ£¿ÓôÃÆ£¿¸ßÐË£¿Ã»ÀíÓÉ£¿¶¼À´ÁÄÌì°É£¡¡ª¡ª 
ÑÅ»¢È«ÐÂÁÄÌìÊÒ! 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

[Emiel Kollof]

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

[Pete French]

> 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

[Kutulu]

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

[Nik Clayton]

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

[Terry Lambert]

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

[Terry Lambert]

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

[Terry Lambert]

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

[Miguel Mendez]

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

[Thomas Hurst]

* 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

[Wilko Bulte]

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

[Matt Heckaman]

-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

Re: Junior Annoying Hacker Task

[Brian T . Schellenberger]

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 
AT&T 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

[Terry Lambert]

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

[Matt Heckaman]

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

[Terry Lambert]

"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...
backup

regedit
Registry
Import Registry File...
backup

> - 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

[Brian T . Schellenberger]

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

[Bosko Milekic]

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