Two comments:
1. Hopefully we will only need to do this on very rare occasions.
They way things are set up, Exim, Courier, and (soon) Apache all
use the user's tokens and there are no special identities. I can
see why domtool needs an identity, though.
2. Do we really need separate identities for separate machines? My
understanding was that the whole service/[EMAIL PROTECTED] convention
was for preventing man-in-the-middle attacks for things like
kerberized telnet. If we're only using kerberos in order to
support AFS, I don't know if it's really necessary.
Also, if we go with a single user per service across all hosts,
we can give it the same userid in /etc/passwd and pts,
eliminating the ID>1000 stuff.
If possible, it would be nice to get a bit of discussion on #2 before
we move forward with this; I think it will save us lots of trouble...
- a
Davor Ocelic <[EMAIL PROTECTED]> writes:
> Hey folks,
>
> In discovering why domtool-server won't start, I identified a group of
> problems in the current setup. The essence is that we don't seem to
> have the same vision of how to allow services to access data in AFS
> space.
>
> After thinking for a while and combining best approaches from the three
> methods we had circulating, here's the final procedure you should follow
> (for installing service "SERVICE" (mysql) on host "HOST" (deleuze)):
>
>
> 1) create local user SERVICE in /etc/passwd:
>
> (usually already done by Debian postinst scripts in form of
> "adduser --system SERVICE". (--system ensures that the
> assigned ID is in range 100 < ID < 1000 .))
>
> 2) create Kerberos principal:
>
> kadmin.local -q "addprinc -policy service -randkey SERVICE/HOST"
>
> 3) export user's keys to /etc/keytabs/SERVICE.HOST:
>
> kadmin.local -q "ktadd -k /etc/keytabs/SERVICE.HOST SERVICE/HOST"
>
> 4) create OpenAFS user SERVICE.HOST
>
> (You must make sure that the UID chosen in AFS is above 1000.
> You can't use UIDs <1000 because those are reserved for local
> system's IDs, and so such uids in AFS would mess up reported Unix
> ownership
> of files).
>
> pts cu SERVICE.HOST.hcoop.net
>
> (P.S. Can you tell pts the minimum ID to assign?)
>
> 5) create OpenAFS group "SERVICE" if it doesn't exist, and add
> SERVICE.HOST to it:
>
> pts cg SERVICE
> pts ad SERVICE.HOST SERVICE
>
> 6) modify service's init script in /etc/init.d/ in the following way:
>
> Change shell at the top of script to "#!/usr/bin/pagsh.openafs"
>
> Change start-stop-daemon invocation in action 'start':
>
> start-stop-daemon --start --pidfile $PIDFILE \
> -c SERVICE:SERVICE \
> --exec /usr/bin/k5start -- -U -b -f
> /etc/keytabs/SERVICE.`hostname` \
> -K 300 -t -p $PIDFILE \
> <The original start command>
>
>
> **Or if the service does not use start-stop-daemon itself, you still
> use it in
> action 'start' to run k5start on a line before <The original start
> command>
> and later in 'stop' to close it:
>
> (start):
> start-stop-daemon --start --pidfile
> /var/run/SERVICE/k5start-SERVICE.pid \
> -c SERVICE:SERVICE \
> --exec /usr/bin/k5start -- -U -b -K 300 -t -p
> /var/run/SERVICE/k5start-SERVICE.pid \
> -f /etc/keytabs/SERVICE.`hostname`
> sleep 2
>
> (stop):
> start-stop-daemon --stop --pidfile
> /var/run/SERVICE/k5start-SERVICE.pid
> rm -f /var/run/SERVICE/k5start-SERVICE.pid
>
> 7) You give permissions in AFS space to group "SERVICE", or to user
> "SERVICE.HOST"
> if specific instance is important. (Mostly, you just add permissions to
> "SERVICE").
>
>
>
> The current system state does not correspond to the setup described above.
> (Due to a
> couple of reasons).
>
> I will give a few hours for eventual comments to this e-mail and then go into
> adjusting
> the systems to above-described policy.
>
> Cya,
> -doc
--
PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380
_______________________________________________
HCoop-SysAdmin mailing list
[email protected]
http://hcoop.net/cgi-bin/mailman/listinfo/hcoop-sysadmin
