Le 28 août 07 à 23:09, Jamie Strandboge a écrit :
On Tue, 2007-08-28 at 16:49 -0400, Mathias Gug wrote:On Tue, Aug 28, 2007 at 03:55:08PM -0400, Jamie Strandboge wrote:My thinking was that I didn't think the samba and nfs-kernel-serverpackages setup a working share out of the box. I admit I haven't looked at the packaging for these lately. I also didn't think that the samba or nfs package should setup this kind of share by default, because it could be annoying for an experienced sysadmin to always have to disableit or change it.If samba and nfs-kernel-server provide all the debconf functionality toget a working share, then you are absolutely correct to not want to split out the functionality.I think they provide the basic functionality. However you cannot setup ashare. I don't think that configuring a share should be done in the postinst package. This is a task that can done multiple times by a the sysadmin, on a daily basis. I'm not sure that dpkg --configure should be used on a daily basis to manage your system.I agree-- I don't think it should be done in postinst either, which is why I thought a simple, small configuration package likesamba-default-shares or nfs-default-exports *might* be appropriate here.My thinking would be that these packages would not be how you wouldnormally administer the system (eg to add/remove shares), but rather tobe used to create a simple share for users to use right away. Experienced admins wouldn't necessarily install these packages, but rather samba and nfs-kernel-server alone. Inexperienced could install these (or the tasks) in order to start working right away. It is *only* intended to get something up and running in a sane configuration quickly for the novice admin.
IMHO, I beleive that we should first define what's the goal of a task. I think that "to get something up and running in a sane configuration quickly for the novice admin" is a good start that we should refine a bit more. If I may propose my 0.2 cents :
a/ A task should allow complete newbye have a basic configuration working out of install with a common set of guidelines between all subcomponent and other tasks. For example the task for file server if asked to work with a previously installed ldap task, should automatically configure samba/ftp to use ldap for authentication.
b/ A task is a set of multiple packages that will work together to acomplish a single macro objective. There no point in having a single package task, we'd better fix the original packaging.
c/ A task is not a configuration utility, it is just a manner to deliver a base configuration that works in a predictable/upgradable/ maintained over time maner.
d/ Tasks needs to be callable after install so that you can revert to the base configuration if you totally messed up without having to reinstall from scratch or have the ability to install a task later on.
e/ Tasks should be as open (and documented) as possible, thefore offering (communities/ISVs/whomever) to propose new tasks that could be eventually included. This would allow for a service model ISV to offer an easy to support config with our distro without having to redo their own from scratch for example.
f/ Tasks should always come common sense security enabled as well as default tuning.
On the theme of what tasks should come next, here are a few suggestions :
- Authentication server (LDAP + WebSSO + CA)- Mail server (preconfigured smtp + pop3 + imap + spamassassin + clamav + webmail + mailman...)
- DB Server ( postgresql | mysql + backup + phpmysql ) - File Server ( ftp + smb + nfs with [Kerberos | LDAP] integration) Just MHO, comments very welcome... Nicolas Barcet <[EMAIL PROTECTED]> http://nicolas.barcet.com« Ce qui compte, ce n’est pas qui vote, mais qui compte les votes ». (Attribué à Joseph Staline)
PGP.sig
Description: Ceci est une signature électronique PGP
-- ubuntu-server mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
