Date: Fri, 26 Oct 2001 17:45:41 +0100 From: Paul Robinson <paul@akita.co.uk> To: Ryan Thompson <ryan@sasknow.com> Cc: freebsd-chat@FreeBSD.ORG Subject: Re: User/virtual administration Message-ID: <20011026174541.E24701@jake.akitanet.co.uk> In-Reply-To: <Pine.BSF.4.21.0110260952530.49287-100000@ren.sasknow.com>; from ryan@sasknow.com on Fri, Oct 26, 2001 at 10:19:51AM -0600 References: <20011026093135.B22182@jake.akitanet.co.uk> <Pine.BSF.4.21.0110260952530.49287-100000@ren.sasknow.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 26, Ryan Thompson <ryan@sasknow.com> wrote: > I like the Ark concept (I really do), but I think it is quite different > than what I am looking for. ARK, like many other packages out there, seems > to be stuck on the concept of service-centric administration (configuring > daemons). That's fine, if you were born thinking like a server. Maybe I > misunderstood their purpose from the few pages of preliminary > documentation that is available. I think you may have misunderstood the final concept. It's early days yet, but the long-term goal is for sysadmins to sit and determine and learn about sensible policies and for all of the rest of the underlying stuff to just be there - e.g. chances are if me and you both want Apache with PHP, we're likely to do the majority of it the same way. The actual dirs where things live might change, as might permissions - that's a policy issue though. So, let's suppose I build a script to install Apache and PHP in a framework that understands your policies - and it just works in your environment as well as it does in mine, excpet it works with your variables. That's the goal of Ark. > My question is WHY do it that way? What are the common tasks that > sysadmins (for now, let's say in a web hosting scenario) want to perform? > Depending on the size of the organization, 90-99% of time is spent on > account management. Adding/removing/modifying users, right? (Come on.. > Tell me I'm wrong.. ;-) OK, you're wrong. If you're spending time doing account management, consider writing the scripts to sit behind the web front-end for your customer services team to handle. Sysadmins should be looking after systems, not accounts. It's even in the job title. :-) Going off-track here, but unless users need a shell, I never put a system in place that would give users an entry in /etc/passwd - if you can put FTP and Mail into MySQL (proftpd, exim), why bother having them lying around in flat files. By putting them into a MySQL table, writing a script to handle account management because laughably trivial. > The trouble is, there is no atomic "add user" command on typical systems. > There are plenty of fine scripts to add users to the passwd database (or > whatever auth db of choice), as well as plenty of methods to add Apache > virtual hosts, DNS zones, etc... but they are all disjoint... When I want > to add a user, I want the sense of completing ONE coherent task.. not > several. The result is a more efficient, less error prone method that > doesn't require intimate knowledge of the configuration formats for 100 > different daemons. That, is ultimately, the aim of Ark. It's nowhere near it now, but that is what I perceive the goal to be. I know exactly what you mean, and what you're talking about is policy development - "This customer should have an FTP account with his webspace, and his domain should point here...", "This guy from sales needs to see how many customers we have live right now...", "Accounts need to be able to block this guys website...", etc. > Anyways, Paul... Not meaning to come down on your suggestion (I'm not)... > Ark looks really good... And something like that, as well, is sorely > needed for administering large installations. Put quite simply, it's just > not the same direction that I'm headed. ;-) Fair enough. I look forward to seeing what you come up with. If you get a webpage up detailing the methodology, post the URL up, and I'm sure lots of people here will be happy to take a look. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011026174541.E24701>