Date: Fri, 31 May 2002 15:51:19 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Daniel Blankensteiner <db@traceroute.dk> Cc: freebsd-arch@freebsd.org Subject: Re: FreeBSD daemon configurations redesign Message-ID: <3CF7FE67.868D4EF9@mindspring.com> References: <F67gL6wxvw0IDT8zAJ90000d078@hotmail.com> <00c601c2082d$bc531ff0$6800a8c0@rafter> <3CF6B300.145E0CD9@mindspring.com> <011201c20832$34404750$6800a8c0@rafter> <3CF6CC39.BFC0A232@mindspring.com> <011001c20885$6dc3db60$6800a8c0@rafter> <3CF7E342.C351A12E@mindspring.com> <01bf01c208ec$b11a7380$6800a8c0@rafter>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CF7FE67.868D4EF9>