date:20110105

Your Bugzilla buglist needs attention.

2011-01-05 Thread drift

[This e-mail has been automatically generated.]

You have one or more bugs assigned to you in the Bugzilla bug tracking system
(http://bugs.skolelinux.org/) that require
attention.

All of these bugs are in the NEW or REOPENED state, and have not been
touched in 7 days or more.
You need to take a look at them, and decide on an initial action.

Generally, this means one of three things:

(1) You decide this bug is really quick to deal with (like, it's INVALID),
and so you get rid of it immediately.
(2) You decide the bug doesn't belong to you, and you reassign it to
someone else. (Hint: if you don't know who to reassign it to, make
sure that the Component field seems reasonable, and then use the
"Reassign bug to default assignee of selected component" option.)
(3) You decide the bug belongs to you, but you can't solve it this moment.
Just use the "Accept bug" command.

To get a list of all NEW/REOPENED bugs, you can use this URL (bookmark
it if you like!):
http://bugs.skolelinux.org/buglist.cgi?bug_status=NEW&bug_status=REOPENED&assigned_to=debian-...@lists.debian.org

Or, you can use the general query page, at
http://bugs.skolelinux.org/query.cgi

Appended below are the individual URLs to get to all of your NEW bugs
that haven't been touched for a week or more.

You will get this message once a day until you've dealt with these bugs!

installer ignores mirror/http/proxy preseeding
-> http://bugs.skolelinux.org/show_bug.cgi?id=1458
ignores mirror/http/hostname preseed
-> http://bugs.skolelinux.org/show_bug.cgi?id=1459

--
To UNSUBSCRIBE, email to debian-edu-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1paik7-00029r...@maintainer.skolelinux.no

Re: NFS4 and Kerberos: A-records for same IP inflate the need for service principals

2011-01-05 Thread Mike Gabriel


Dear Andreas, dear Petter,

On Mi 05 Jan 2011 19:10:24 CET Petter Reinholdtsen wrote:


[Andreas B. Mundt]

I tried to find the reason for these corresponding A-records,


There are two aspects coming together to cause this effect.  We use
strict mode in powerdns, allowing shared A/PTR entries in LDAP, and
the fact that SRV and MX records need to point to A records.  As our
design allow for scaling by moving individual services out by changing
DNS entries, we need to use the service names in DNS.  And thus, we
end up with several PTR entries for 10.0.2.2. :/

Not quite sure how to best adjust this and still get a sensible and
scalable solution.


I am not an expert regarding that stuff and I don't know if there
are other ways to achieve the desired. However, it looks as with the
current setup we need service principals for all host aliases.


That isn't too bad, is it?  It can be added automatically at install
time, right?


Kerberos demands a correct ReverseDNS setup. It can handle multiple  
A-Records for the same IP. Important is that the host principal's IP  
correctly reverse-resolve to the hostname used in the Kerberos host  
principal.


For a correctly working NFS4+Kerberos setup you need (it's quite a  
while ago that I set up my NFS4, so some things might be inaccurate):


  o host principals for all clients and servers of the form:
host/@

so for tjener, this is
host/tjener.int...@intern

and for clients this is
host/dhcp001.int...@intern
...

  o each host has a keytab entry stored locally that corresponds to the host
principal. This keytab hash must be distributed during client installation
(or retrieved via kadmin-server)

  o each service needs a service principal of the form
/@

so these might be:
ldap/tjener.int...@intern
nfs/tjener.int...@intern
etc.

  o these service principals' credentials have to be distributed to all
clients' keytab files individually
on dhcp001: kadmin -q ktadd host/dhcp001.int...@intern
kadmin -q ktadd nfs/dhcp001.int...@intern
on dhcp002: kadmin -q ktadd host/dhcp002.int...@intern
kadmin -q ktadd nfs/dhcp002.int...@intern
...

  o and then you need principals for each user (and pam_krb5.so to get the
tickets for each user on login)

  o some time during squeeze development an extra line in  
/etc/krb5.conf became

necessary:

[libdefaults]
default_realm = INTERN
allow_weak_crypto = true # needed for NFSv4

  o using NFS4+Krb5 starts really making sense when using at least  
sec=krb5i as

mount option. Then you really need a user's Krb5 ticket to be able to
connect to an NFS4 share

  o for this to work you need Kerberos authentication (PAM, see above)
  o and also a running idmapd (nfs-common package)

  o Kerberos5 (MIT) has an LDAP backend, not sure about Heimdal.  
Kerberos is or

was problematic about U.S. export restrictions/regulations. So in this
respect the choice should be Heimdal, but I am not sure if Heimdal has an
LDAP backend...

  o authentication to LDAP via Kerberos can be handled by saslauthd (which is
very neat).

For NFSv4 on Skolelinux I do recommend

  o sec=krb5p for teachers and
  o sec=krb5i for students.

I also recommend one autofs rule for each user and to store them in  
LDAP (nisMapName obejctclass). I am not sure, if Skolelinux's  
automount mechanism already uses this setup. Then at least you can  
store the NFS mount options in LDAP and differentiate between user  
groups concerning nfs4-integrity mounts (sec=krb5i) and nfs4-privacy  
mounts (sec=krb5p).


Mounting all NFS shares via krb5p (or NFS-encrypting one big mount  
point like /skole/home/tjener0) I do absolutely not recommend. NFSv4  
encryption is quite CPU-sucking...


I am really interested in NFSv4+Kerberos5 integration in Skolelinux.  
So if I can be of any help, let me know.


Regards,
Mike

--

DAS-NETZWERKTEAM
mike gabriel, dorfstr. 27, 24245 barmissen
fon: +49 (4302) 281418, fax: +49 (4302) 281419

GnuPG Key ID 0x1943CA5B
mail: m.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


pgpuFWy7vqmOG.pgp
Description: Digitale PGP-Unterschrift

Re: NFS4 and Kerberos: A-records for same IP inflate the need for service principals

2011-01-05 Thread Andreas B. Mundt

On Wed, Jan 05, 2011 at 07:10:24PM +0100, Petter Reinholdtsen wrote:
[...]
> > I am not an expert regarding that stuff and I don't know if there
> > are other ways to achieve the desired. However, it looks as with the
> > current setup we need service principals for all host aliases.
> 
> That isn't too bad, is it?  It can be added automatically at install
> time, right?
> 

Yes, the creation of the principals is done during installation. The
script kerberos-kdc-init would contain something like:

for name in tjener.intern kerberos.intern ldap.intern domain.intern 
postoffice.intern syslog.intern; do 
## create machine principals and add them to the keytab:
kadmin.local -q "addprinc -randkey host/$name"
kadmin.local -q "ktadd host/$name"
## create service principals and add them to the keytab:
kadmin.local -q "addprinc -randkey nfs/$name"
kadmin.local -q "ktadd nfs/$name"
kadmin.local -q "addprinc -randkey cifs/$name"
kadmin.local -q "ktadd cifs/$name"
kadmin.local -q "addprinc -randkey ldap/$name"
kadmin.local -q "ktadd -k /etc/krb5.keytab.ldap ldap/$name"
kadmin.local -q "addprinc -randkey imap/$name"
kadmin.local -q "ktadd -k /etc/krb5.keytab.imap imap/$name"
kadmin.local -q "addprinc -randkey smtp/$name"
kadmin.local -q "ktadd -k /etc/krb5.keytab.smtp smtp/$name"
done
chown dovecot:dovecot /etc/krb5.keytab.imap
chown openldap:openldap /etc/krb5.keytab.ldap
chown Debian-exim:Debian-exim /etc/krb5.keytab.smtp

However, I don't know if working with that mess of principals is a
good idea in the end. From a first look it seems like making an
already complicated and hard-to-debug-thing even more confusing, which
also applies to moving individual services to other machines.

Best regards,

 Andi


-- 
To UNSUBSCRIBE, email to debian-edu-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110105195000.ga12...@flashgordon

Re: NFS4 and Kerberos: A-records for same IP inflate the need for service principals

2011-01-05 Thread Petter Reinholdtsen

[Andreas B. Mundt]
> I tried to find the reason for these corresponding A-records,

There are two aspects coming together to cause this effect.  We use
strict mode in powerdns, allowing shared A/PTR entries in LDAP, and
the fact that SRV and MX records need to point to A records.  As our
design allow for scaling by moving individual services out by changing
DNS entries, we need to use the service names in DNS.  And thus, we
end up with several PTR entries for 10.0.2.2. :/

Not quite sure how to best adjust this and still get a sensible and
scalable solution.

> I am not an expert regarding that stuff and I don't know if there
> are other ways to achieve the desired. However, it looks as with the
> current setup we need service principals for all host aliases.

That isn't too bad, is it?  It can be added automatically at install
time, right?

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-edu-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110105181024.ga24...@login1.uio.no

NFS4 and Kerberos: A-records for same IP inflate the need for service principals

2011-01-05 Thread Andreas B. Mundt

Hi all,

the last days I found a little time to have a look into the issue of
using NFSv4 (and perhaps Kerberos) to mount the home directories.

I first configured NFS4 to export the home directories. After that I
tried kerberos authentication. However, I observed that it works only
in some cases, in most of the attempts to mount the share a missing
principal of the form nfs/x...@intern was reported, where XXX is one of
the hostnames (and not tjener.intern) reported by this command:

r...@tjener:~# host 10.0.2.2
2.2.0.10.in-addr.arpa domain name pointer tjener.intern.
2.2.0.10.in-addr.arpa domain name pointer kerberos.intern.
2.2.0.10.in-addr.arpa domain name pointer ldap.intern.
2.2.0.10.in-addr.arpa domain name pointer domain.intern.
2.2.0.10.in-addr.arpa domain name pointer postoffice.intern.
2.2.0.10.in-addr.arpa domain name pointer syslog.intern.

If I understand things correctly, mounting the share with

mount -t nfs4 -o sec=krb5 tjener.intern:/ /skole/tjener/

converts tjener.intern into an IP adress and that address back to the
(full qualified) hostname. So only if by chance tjener.intern is used
for the lookup, the (existing) nfs/tjener.int...@intern principal is
used and things work as they should. If another hostname is used,
things fail because there is no corresponding service principal.

I tried to find the reason for these corresponding A-records, they
have been changed in commit 71704.
(http://svn.debian.org/wsvn/debian-edu/trunk/src/debian-edu-config/ldap-bootstrap/?rev=71704&sc=1>)

I am not an expert regarding that stuff and I don't know if there are
other ways to achieve the desired. However, it looks as with the
current setup we need service principals for all host aliases.

Best regards,

Andi

25 matches

Mail list logo