[clue-admin] User setup for "member" accounts

[Collins Richey]

On Wed, 29 Dec 2004 12:02:23 -0700, Jed S. Baer <thag at frii.com> wrote:

> > First question: requirements?
> 
> I went through the admin archives, to see what I could find about this.
> 
> http://clue.denver.co.us/pipermail/clue-admin/2003-July/001134.html
> http://clue.denver.co.us/pipermail/clue-admin/2003-August/001189.html
> http://clue.denver.co.us/pipermail/clue-admin/2003-November/001326.html
> http://clue.denver.co.us/pipermail/clue-admin/2004-March/001495.html
> 

Some comments

> Our requirements are derived from what we promise as benefits of
> membership. The outline from the past is:
>  - Email alias.
>  - Public HTML account (~user) - 15 MB

How best to support these items is the current discussion.

>  - SME server (Crawford).

What in blazes is this - oops I found out via google. This is a major
project. Let Crawford define the need, make suggestions, etc.

>  - Invited to social events (BBQs, beer fests).
>  - Participate in door prizes -- paid members only or $2 @ door
>    for one night.
>  - Printed name tags.
>  - Temporary name tags for one-night members.
>  - Give them a prize for the membership -- T-shirt, book, etc.
>  - Membership card.
> 

These extras are outside the realm of the current discussion

> The account disk space was later revised to 10MB.
> 
> The SME server product was mentioned as a way to ease management and
> setup, but the link -- www.e-smith.org -- Crawford later provided now goes
> to some commercial outfit, where I saw no mention of the GPL.
> 

Google currently returns information about a gpl version of SME which
is documented at Lycoris User Contribs, i.e.

http://contribs.org/modules/news/


> > Next question: do we need shell accounts?
> 
> Not if the only reason is for maintaining individual sites, which can be
> done using scp or sftp. sftp supports rm and rmdir.
> 

Based on the requirements above, I recommend that we NOT provide login
accounts for members. Obviously we are going to continue to provide
login accounts for admins, and we need to take steps to secure those
accounts (PK authentication, etc.), but removing member logins is a
big step toward securing the server.

So, in my estimation,  we are down to the following:

1. Maintaining email aliases. Just as we don't provide login accounts
for members, I recomment that we NOT provide an external means to
update the aliases file. We can provide an online form that submits a
request to the appropriate admin (or group of admins).

2. Setup non-login accounts for members (shell: /bin/false or
equivalent). I have scripts that can be modified to automate this
process for existing and new members. Users will have a ~/public_html
directory that can be updated by them (how?).

3. This leaves the method that users employ to update their
~/public_html up for grabs. Jed has suggested scp or sftp. There's
also the possibility of including a member update function in the web
site redesign. Your thoughts, please.

> While looking for stuff, I noticed this, which, in retrospect, seems more
> ominous than it did at the time:
> http://clue.denver.co.us/pipermail/clue-admin/2003-December/001335.html
> 

IMO, providing incoming FTP on our server is a recipe for disaster. We
should close any FTP ports immediately. Perhaps Jed can comment more
about sftp.

-- 
 Collins