|
|
|
|
|
|
| Author |
Message |
Daniel Blankensteiner
*nix forums beginner
Joined: 30 May 2002
Posts: 24
|
 Posted: Fri May 31, 2002 7:31 am Post subject:
Re: FreeBSD daemon configurations redesign
|
|
|
----- Original Message -----
From: "Mike Barcroft" <mike@freebsd.org>
To: "Daniel Blankensteiner" <db@traceroute.dk>
| Quote: | Daniel Blankensteiner <db@traceroute.dk> writes:
Do you find it logical that all the ftp config files are floating
around
in /etc? Together with sendmail and other config files?
I am just talking about cleaning up in /etc.
We usually start creating directories in /etc after we have several
configuration files to put there. For instance: /etc/namedb/,
/etc/mail/, /etc/ssh/. It might not be a bad idea to create an
/etc/ftpd/.
|
Glad you agree on that :-)
br
db
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
 |
Daniel Blankensteiner
*nix forums beginner
Joined: 30 May 2002
Posts: 24
|
| Posted: Fri May 31, 2002 7:51 am Post subject:
Re: FreeBSD daemon configurations redesign
|
|
|
----- Original Message -----
From: "Andrew Reilly" <areilly@bigpond.net.au>
| Quote: | On Fri, 2002-05-31 at 01:45, Daniel Blankensteiner wrote:
I mean by making the system more logical organized/structured and
thereby
more
well-arranged, this should lead to a more easy to configure and
thereby
more secure system, without reducing the power and opportunities
of the system. I am talking about giving daemons special treatment.
You should check out the sysutils/daemontools port. It gets a _lot_
right, in my opinion. OK, you have to tweak it so that log files go
into /var/log/foo-service/ instead of /etc/foo-service/log/main/, but
that's not hard to do.
Even the configuration mechanism (envdir: set environment variables
according to the contents of files in the named directory) is neat.
Thats part of the blurry line between the design of the daemons
themselves and the control framework, I guess.
Multilog handles log file rotation naturally, without having to
interrupt the daemon to tell it to close and re-open the file.
Process signalling without needing write access to /var/run, (to write
a
PID file), so daemons can run as non-root users and not require
looking
their process number up with ps in order to send them a signal.
Many good design ideas.
|
Ok and we should discuss every (serious) idea and do it, if the outcome
is a better system.
br
db
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Fri May 31, 2002 6:55 pm Post subject:
Re: FreeBSD daemon configurations redesign
|
|
|
Daniel Blankensteiner wrote:
| Quote: | From: "Terry Lambert" <tlambert2@mindspring.com
To: "Daniel Blankensteiner" <db@traceroute.dk
I also think it's bad to put things under /etc, since I think
/etc should be read-only. I think that eventually, we will
see all such things live under /var.
I am only talk about config files, the binaries and log should not be in
here.
|
I'm also taling about config files.
Seperate config files is a bad idea. We tolerate it now because
a lot of things wouldn't fit into rc.conf (like the sendmail
configuration data). For things that can, they should. Your
examples were all things that can. I don't understand the
benefit of breaking them up, except to have more files to worry
about, and more things that need to be writeable (or symlinked
and moved, when / isn't writeable).
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Daniel Blankensteiner
*nix forums beginner
Joined: 30 May 2002
Posts: 24
|
| Posted: Fri May 31, 2002 7:46 pm Post subject:
Re: FreeBSD daemon configurations redesign
|
|
|
----- Original Message -----
From: "Terry Lambert" <tlambert2@mindspring.com>
| Quote: | I am only talk about config files, the binaries and log should not
be in
here.
I'm also taling about config files.
Seperate config files is a bad idea. We tolerate it now because
a lot of things wouldn't fit into rc.conf (like the sendmail
configuration data). For things that can, they should. Your
examples were all things that can. I don't understand the
benefit of breaking them up, except to have more files to worry
about, and more things that need to be writeable (or symlinked
and moved, when / isn't writeable).
|
I think it is easier to setup, let's say FTP, if you know ALL the config
files are in /etv/daemons/ftp. And the only place to start the ftpd from
when booting, is from /etc/daemons/startup.
When you add a user, you have to grand him or deny him access to
services. This you do by changing a lot of config files, maybe
forgetting some? So a central access file, is maybe not so bad.
When more services are added, /etc will "explode". We already got
/etc/mail and /etc/ssh, why not /etc/ftp? And then put them in
/etc/daemons/, it makes more sence.
db
db
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Fri May 31, 2002 8:51 pm Post subject:
Re: FreeBSD daemon configurations redesign
|
|
|
Daniel Blankensteiner wrote:
| Quote: | I think it is easier to setup, let's say FTP, if you know ALL the config
files are in /etv/daemons/ftp. And the only place to start the ftpd from
when booting, is from /etc/daemons/startup.
|
It's even easier when you don't supply knobs to twiddle in the first
place. Can't pick a wrong setting, if there is no way to change it
from a right setting...
| Quote: | When you add a user, you have to grand him or deny him access to
services. This you do by changing a lot of config files, maybe
forgetting some? So a central access file, is maybe not so bad.
When more services are added, /etc will "explode". We already got
/etc/mail and /etc/ssh, why not /etc/ftp? And then put them in
/etc/daemons/, it makes more sence.
|
I will share with you "Lessons I have learned about doing business
using Open Source: Lesson #31":
There are three ways to view this:
o System-centric
o Service-centric
o User-centric
Right now, things are (mostly) system-centric. In your example of
adding a user and establishing permissions, you have a problem which
is user-centric. Then you propose a solution which is service-centric.
This doesn't make a lot of sense.
When you are trying to create a user-centric model (e.g. the InterJet
was such a model), then the best possible world is to implement a
user-centric parameter store.
When you have to live in the world of attempting to leverage existing
source code, then you have to accept some limitations that come with
that existing source code.
This was a lesson that some of our UI people never learned, and so
they tried to change some basic underlying paradigms. Yes, it's
possible to do what they wanted (though, probably not wise, if you
get right down to it), but the cost would be to not be able to use
the exisiting code out there for leverage: the job would have to be
done "from scratch"... and there are litterally hundreds of thousands
of man years of effort in software like DNS and sendmail, etc., that
it would be a shame to have to duplicate.
Most companies that try to base products on Open Source really fail
to learn this lesson: sometimes you have to bend to the software,
rather than attempt to bend the software to your will. Then, of
course, the companies themselves fail.
The best compromise for a user-centric administrative view is to
leave the configuration file layouts and formats alone, and put
your own database out there. Then derive the configuration data
for the software -- in its native format -- from the contents of
your magic user-centric database.
There are a couple of interesting problems you end up needing to
solve when you take this approach, but they are ultimatrely
soluable.
I think you are much better off trying to build something like
this (if you are smart, it will probably be based on LDAP), than
you are in trying to change every piece of software out there to
fit a paradigm that is specific to FreeBSD, and will lose you the
third party maintenance that makes the current model valuable:
it offloads maintenance onto third parties.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Daniel Blankensteiner
*nix forums beginner
Joined: 30 May 2002
Posts: 24
|
| Posted: Fri May 31, 2002 9:29 pm Post subject:
Re: FreeBSD daemon configurations redesign
|
|
|
----- Original Message -----
From: "Terry Lambert" <tlambert2@mindspring.com>
| Quote: | I will share with you "Lessons I have learned about doing business
using Open Source: Lesson #31":
There are three ways to view this:
o System-centric
o Service-centric
o User-centric
Right now, things are (mostly) system-centric. In your example of
adding a user and establishing permissions, you have a problem which
is user-centric. Then you propose a solution which is
service-centric.
This doesn't make a lot of sense.
When you are trying to create a user-centric model (e.g. the InterJet
was such a model), then the best possible world is to implement a
user-centric parameter store.
When you have to live in the world of attempting to leverage existing
source code, then you have to accept some limitations that come with
that existing source code.
This was a lesson that some of our UI people never learned, and so
they tried to change some basic underlying paradigms. Yes, it's
possible to do what they wanted (though, probably not wise, if you
get right down to it), but the cost would be to not be able to use
the exisiting code out there for leverage: the job would have to be
done "from scratch"... and there are litterally hundreds of thousands
of man years of effort in software like DNS and sendmail, etc., that
it would be a shame to have to duplicate.
|
UI?
| Quote: | Most companies that try to base products on Open Source really fail
to learn this lesson: sometimes you have to bend to the software,
rather than attempt to bend the software to your will. Then, of
course, the companies themselves fail.
The best compromise for a user-centric administrative view is to
leave the configuration file layouts and formats alone, and put
your own database out there. Then derive the configuration data
for the software -- in its native format -- from the contents of
your magic user-centric database.
There are a couple of interesting problems you end up needing to
solve when you take this approach, but they are ultimatrely
soluable.
I think you are much better off trying to build something like
this (if you are smart, it will probably be based on LDAP), than
you are in trying to change every piece of software out there to
fit a paradigm that is specific to FreeBSD, and will lose you the
third party maintenance that makes the current model valuable:
it offloads maintenance onto third parties.
|
LDAP?
Ok, I did not know it all had to be rewritten from scratch. I thought
you just had to rewrite where the daemons store it's confil files.
Making an interface to all these config files (like you said), is maybe
a better idea.
I would like to design this, but I don't think my code will be good
enogh for FreeBSD?
br
db
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Daniel Blankensteiner
*nix forums beginner
Joined: 30 May 2002
Posts: 24
|
| Posted: Fri May 31, 2002 9:34 pm Post subject:
Re: FreeBSD daemon configurations redesign
|
|
|
----- Original Message -----
From: "Gordon Tetlow" <gordon@FreeBSD.org>
| Quote: | The problem with this is that the past 15 years of software doesn't
work
this way. It would take a fair amount of legwork to go through and
hammer
everything into this mold that would be FreeBSD-specific. I think it
would
be *very* difficult to get buy-in from all the projets out there that
we
might potentially use. It's a lot of work already keeping the
contrib'ified sources in sync with the vendors, now imagine
customizing
everything so it was in /etc/daemons/*
It's a lot of work to do what you propose.
|
Ok, the idea was good and it can't be done. Some of the things I was
talking about can't be done whitout this "new system", but some of the
things we can make by faking central control.
If you think this is a good idea, then I will be glad (very glad) to
help out, anyway I can.
br
db
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Gordon Tetlow
*nix forums beginner
Joined: 31 May 2002
Posts: 42
|
| Posted: Fri May 31, 2002 11:04 pm Post subject:
Re: FreeBSD daemon configurations redesign
|
|
|
On Fri, 31 May 2002, Daniel Blankensteiner wrote:
| Quote: | I think it is easier to setup, let's say FTP, if you know ALL the config
files are in /etv/daemons/ftp. And the only place to start the ftpd from
when booting, is from /etc/daemons/startup.
When you add a user, you have to grand him or deny him access to
services. This you do by changing a lot of config files, maybe
forgetting some? So a central access file, is maybe not so bad.
When more services are added, /etc will "explode". We already got
/etc/mail and /etc/ssh, why not /etc/ftp? And then put them in
/etc/daemons/, it makes more sence.
|
The problem with this is that the past 15 years of software doesn't work
this way. It would take a fair amount of legwork to go through and hammer
everything into this mold that would be FreeBSD-specific. I think it would
be *very* difficult to get buy-in from all the projets out there that we
might potentially use. It's a lot of work already keeping the
contrib'ified sources in sync with the vendors, now imagine customizing
everything so it was in /etc/daemons/*
It's a lot of work to do what you propose.
-gordon
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Daniel Blankensteiner
*nix forums beginner
Joined: 30 May 2002
Posts: 24
|
| Posted: Sat Jun 01, 2002 7:54 am Post subject:
Re: FreeBSD daemon configurations redesign
|
|
|
----- Original Message -----
From: "Terry Lambert" <tlambert2@mindspring.com>
| Quote: | Making an interface to all these config files (like you said), is
maybe
a better idea.
Not what I said. I said that you should build a central data
store for configuration data, and then derive the real configuration
files, in whatever format is expected by the daemon, from the data
in the central configuration store.
|
That was also what I meant :-)
But like you said, I/we should stop writting in -arch.
br
db
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Wes Peters
*nix forums addict
Joined: 09 Apr 2002
Posts: 90
|
| Posted: Sat Jun 01, 2002 1:58 pm Post subject:
Re: FreeBSD daemon configurations redesign
|
|
|
Terry Lambert wrote:
| Quote: |
Daniel Blankensteiner wrote:
From: "Andre Oppermann" <oppermann@pipeline.ch
Daniel, Terry, whoever,
Please move this discussion from -arch to -chat. F'upt set.
Is this not the right group to dissuss the FreeBSD design?
freebsd-chat is certainly not.
Then tell me, if I want to create a debate about changing /etc where do
I write to?
He was being less polite than I was.
|
Perhaps in setting follups to chat he was. In asking you to move a
system architecture discussion to -arch, he was just trying to keep the
noise level on -developers down.
| Quote: | He's saying he likes things just fine the way they are, and so
there's no need to discuss them.
I'm saying that this has been discussed to death, the conclusion
is a given, and that Eric Melville and others are already on it,
so you should either get with them, or look at the archives to
see how your discussion will end.
|
People used to say that about the rc system also, and one of these
days we're going to actually have the lukem rc system imported and
working, with improvements no less. The conclusion of the rc
"discussions" always drew was that the SysV init system was too
weak to bother moving to. Luke finally came up with something that
is demonstrably better, and implemented it in NetBSD. The work to
import it to FreeBSD has been slow, but it is happening, and it is
enough of an improvement to bother with.
So, the bar for your design has been set. Is breaking up the system
configuration into all those little bitty files really an improvement?
Discuss how this will improve the system, rather than just calling the
existing implementation "not designed" and flinging around a few
directory trees. Tell us why and how this will improve the system, how
it will interact with SNMP or something like that, etc. Give us a
reason to believe, other than "it's better because Daniel designed it."
Some of the people who developed the existing system weren't complete
buffoons, you know.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
wes@softweyr.com http://softweyr.com/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Wes Peters
*nix forums addict
Joined: 09 Apr 2002
Posts: 90
|
| Posted: Sat Jun 01, 2002 2:09 pm Post subject:
Re: FreeBSD daemon configurations redesign
|
|
|
Terry Lambert wrote:
| Quote: |
Daniel Blankensteiner wrote:
I think it is easier to setup, let's say FTP, if you know ALL the config
files are in /etv/daemons/ftp. And the only place to start the ftpd from
when booting, is from /etc/daemons/startup.
It's even easier when you don't supply knobs to twiddle in the first
place. Can't pick a wrong setting, if there is no way to change it
from a right setting...
When you add a user, you have to grand him or deny him access to
services. This you do by changing a lot of config files, maybe
forgetting some? So a central access file, is maybe not so bad.
When more services are added, /etc will "explode". We already got
/etc/mail and /etc/ssh, why not /etc/ftp? And then put them in
/etc/daemons/, it makes more sence.
I will share with you "Lessons I have learned about doing business
using Open Source: Lesson #31":
There are three ways to view this:
o System-centric
o Service-centric
o User-centric
Right now, things are (mostly) system-centric. In your example of
adding a user and establishing permissions, you have a problem which
is user-centric. Then you propose a solution which is service-centric.
This doesn't make a lot of sense.
When you are trying to create a user-centric model (e.g. the InterJet
was such a model), then the best possible world is to implement a
user-centric parameter store.
When you have to live in the world of attempting to leverage existing
source code, then you have to accept some limitations that come with
that existing source code.
This was a lesson that some of our UI people never learned, and so
they tried to change some basic underlying paradigms. Yes, it's
possible to do what they wanted (though, probably not wise, if you
get right down to it), but the cost would be to not be able to use
the exisiting code out there for leverage: the job would have to be
done "from scratch"... and there are litterally hundreds of thousands
of man years of effort in software like DNS and sendmail, etc., that
it would be a shame to have to duplicate.
Most companies that try to base products on Open Source really fail
to learn this lesson: sometimes you have to bend to the software,
rather than attempt to bend the software to your will. Then, of
course, the companies themselves fail.
The best compromise for a user-centric administrative view is to
leave the configuration file layouts and formats alone, and put
your own database out there. Then derive the configuration data
for the software -- in its native format -- from the contents of
your magic user-centric database.
|
This is exactly the approach DoBox took to the problem. The DoBox
user database (implemented in PostgreSQL, but could be anything) was
the central store for all of the user information. Anytime a user
was addeded, deleted, or changed, an outcall was made to a program
that exported the database to whatever external configurations were
needed. It worked quite well, modulo a few potention race conditions
that were solved with a sledgehammer (giant-type semaphore).
| Quote: | There are a couple of interesting problems you end up needing to
solve when you take this approach, but they are ultimatrely
soluable.
|
The solutions often end up simpler than the problem would seem in the
first place. You get to encapsulate the user design stuff in the
database and handle all the hard icky stuff like configuring mail
account information in a separate program the UI designers never
have to worry about.
| Quote: | I think you are much better off trying to build something like
this (if you are smart, it will probably be based on LDAP), than
you are in trying to change every piece of software out there to
fit a paradigm that is specific to FreeBSD, and will lose you the
third party maintenance that makes the current model valuable:
it offloads maintenance onto third parties.
|
Yes. Anyone looking to "improve" the configuration of FreeBSD, or any
other network-attached system, needs to consider LDAP and SNMP. Plus
whatever their eventual replaces will be.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
wes@softweyr.com http://softweyr.com/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Daniel Blankensteiner
*nix forums beginner
Joined: 30 May 2002
Posts: 24
|
| Posted: Sat Jun 01, 2002 3:18 pm Post subject:
Re: FreeBSD daemon configurations redesign
|
|
|
----- Original Message -----
From: "Wes Peters" <wes@softweyr.com>
| Quote: | So, the bar for your design has been set. Is breaking up the system
configuration into all those little bitty files really an improvement?
|
Little bitty files? I am just talking about putting all the ftp config
files in /etc/ftp
and then all daemon dir's in /etc/daemons. But as I was told, this will
be to much work.
| Quote: | Discuss how this will improve the system, rather than just calling the
existing implementation "not designed" and flinging around a few
directory trees. Tell us why and how this will improve the system,
how
it will interact with SNMP or something like that, etc. Give us a
reason to believe, other than "it's better because Daniel designed
it."
Some of the people who developed the existing system weren't complete
buffoons, you know.
|
I said in the very first mail, that this is not a well thought out plan.
I have never said or hinted that the people who designed /etc are
buffoons (what ever that is), so just relax! But a lot of files have be
add to /etc and I was asking you if we could clean it up and gave a
suggestion of how it could be done, regarding daemons.
The reason to do this was to make user access, daemons configuration and
logging more simple, which would improve security.
br
db
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Cy Schubert - CITS Open S
*nix forums beginner
Joined: 14 May 2002
Posts: 8
|
| Posted: Sun Jun 02, 2002 2:30 pm Post subject:
Re: FreeBSD daemon configurations redesign
|
|
|
In message <3CF7E342.C351A12E@mindspring.com>, Terry Lambert writes:
| Quote: | Daniel Blankensteiner wrote:
From: "Terry Lambert" <tlambert2@mindspring.com
To: "Daniel Blankensteiner" <db@traceroute.dk
I also think it's bad to put things under /etc, since I think
/etc should be read-only. I think that eventually, we will
see all such things live under /var.
I am only talk about config files, the binaries and log should not be in
here.
I'm also taling about config files.
Seperate config files is a bad idea. We tolerate it now because
a lot of things wouldn't fit into rc.conf (like the sendmail
configuration data). For things that can, they should. Your
examples were all things that can. I don't understand the
benefit of breaking them up, except to have more files to worry
about, and more things that need to be writeable (or symlinked
and moved, when / isn't writeable).
|
IBM's ODM gives you the best of both worlds, a centrally managed
database which generates our beloved files. The AIX team here has yet
to see it break but they shudder to think what they'd do if it did.
Ideally what I would like to see is a port of Tivoli to FreeBSD.
--
Regards, Phone: (250)387-8437
Cy Schubert Fax: (250)387-5766
Team Leader, Sun/Alpha Team Email: Cy.Schubert@osg.gov.bc.ca
Open Systems Group, CITS
Ministry of Management Services
Province of BC
FreeBSD UNIX: cy@FreeBSD.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Wes Peters
*nix forums addict
Joined: 09 Apr 2002
Posts: 90
|
| Posted: Mon Jun 03, 2002 9:18 pm Post subject:
Re: FreeBSD daemon configurations redesign
|
|
|
Cy Schubert - CITS Open Systems Group wrote:
| Quote: |
In message <3CF7E342.C351A12E@mindspring.com>, Terry Lambert writes:
Daniel Blankensteiner wrote:
I'm also taling about config files.
Seperate config files is a bad idea. We tolerate it now because
a lot of things wouldn't fit into rc.conf (like the sendmail
configuration data). For things that can, they should. Your
examples were all things that can. I don't understand the
benefit of breaking them up, except to have more files to worry
about, and more things that need to be writeable (or symlinked
and moved, when / isn't writeable).
IBM's ODM gives you the best of both worlds, a centrally managed
database which generates our beloved files. The AIX team here has yet
to see it break but they shudder to think what they'd do if it did.
|
They haven't been around long enough then. I used to explode the
ODM on AIX 3.1.5 on a daily basis. I would've been much fonder of
ODM back then if IBM had actually bothered to produce some readable
documentation on it; it is a good system once they stabilized it
around AIX 3.2.3 or so.
| Quote: | Ideally what I would like to see is a port of Tivoli to FreeBSD.
|
Sorry, Unisys wouldn't let us get away with that. </oops>
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
wes@softweyr.com http://softweyr.com/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Andrew Reilly
*nix forums Guru Wannabe
Joined: 26 Apr 2002
Posts: 148
|
| Posted: Wed Jun 12, 2002 4:36 am Post subject:
Re: FreeBSD daemon configurations redesign
|
|
|
On Sat, 2002-06-01 at 08:51, Terry Lambert wrote:
| Quote: | Most companies that try to base products on Open Source really fail
to learn this lesson: sometimes you have to bend to the software,
rather than attempt to bend the software to your will.
|
It just occurred to me that Apple must be encountering this problem with
OS-X. To whatever extent it is possible to configure the daemons that
they inherited from BSD with their GUI and NetInfo services, anyway. I
don't own a Mac, so I don't know how well they're doing with this.
Anyone have more info/experience?
How close is NetInfo to LDAP, conceptually, in the sense of distributed
database thingies?
Is there any released Darwin code that would be useful to consider
rolling back into FreeBSD in this regard?
--
Andrew
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Thu Jan 08, 2009 6:00 am | All times are GMT
|
|
MPAA | Loans | Debt Consolidation | Bankruptcy | Credit Cards
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
BSD
»
FreeBSD
»
mail-lists
»
Architecture
