I decided to reduce complexity and remove ldap from the equation, since it
wasn't really utilized. I then updated the nsswitch.conf and pam.d confs
accordingly.
Now, I have a single client machine (VM) that works as intended using gdm
gui login. Strangely enough, I cannot make other clients to
On Wed, 2 Oct 2013 14:32:00 +0300 (EEST)
Jukka Tuominen jukka.tuomi...@finndesign.fi wrote:
gdm-simple-slave[749]: WARNING: Failed to add user authorization: could
not find user username on system
**
ERROR:gdm-simple-slave.c:397:start_session_timeout: assertion failed:
(auth_file != NULL)
On 10/02/2013 01:42 PM, Jukka Tuominen sent:
servers, and a libnss-afs package to pass on (afs?) metadata (+ other
Surprised you got libnss-afs to build against 1.6.*. The openafs headers
are missing some key stuff.
nsswitch.conf BTW
passwd: afs files
group: afs files afspag
shadow:
On 10/02/2013 01:42 PM, Jukka Tuominen sent:
servers, and a libnss-afs package to pass on (afs?) metadata (+ other
Surprised you got libnss-afs to build against 1.6.*. The openafs headers
are missing some key stuff.
Actually, I found a .deb from /afs/megacz.com/pub/software/libnss-afs/
On Wed, 2 Oct 2013 20:42:18 +0300 (EEST)
Jukka Tuominen jukka.tuomi...@finndesign.fi wrote:
nsswitch.conf BTW
passwd: afs files
group: afs files afspag
shadow: files
Where is your home directory information stored? It's not in afs; we
don't have a place for that that I'm aware of. The
On Wed, 2 Oct 2013 20:42:18 +0300 (EEST)
Jukka Tuominen jukka.tuomi...@finndesign.fi wrote:
nsswitch.conf BTW
passwd: afs files
group: afs files afspag
shadow: files
BTW, I tried to change the order, but no change there.
Where is your home directory information stored? It's not in
On Wed, 2 Oct 2013 21:39:44 +0300 (EEST)
Jukka Tuominen jukka.tuomi...@finndesign.fi wrote:
Try running:
$ getent passwd username
on both systems. Does the output differ?
No, both succeed.
Okay, then I don't know what gdm is complaining about. I assume from
your previous mails that
Haven't followed the entire discussion, but I would use vos dump
| vos restore to copy the data if this hasn't already been ruled
out.
Keeps ACLs/mountpoints/data ...
Kim
On Tue Sep 24 15:07:44 CDT 2013, Andrew Deason
adea...@sinenomine.net wrote:
On Tue, 24 Sep 2013 22:50:47 +0300
I'm currently trying to figure out the ldap part. With help, I got access to
the afs content without moving it. Users are reintroduced to krb, both afs and
ldap preserved their user data.
I exported ldap data into a text file and replaced old domains with new ones.
Then I imported it back.
Thanks to help, I'm now in the phase where I can kinit;aklog succesfully
as root/admin to the new domain, but I can only see the directory
structure, and not access either the existing /service or homedirs. I
haven't recreated any user accounts so far, since I've made a script to
keep
On Tue, 24 Sep 2013 11:56:29 +0300 (EEST)
Jukka Tuominen jukka.tuomi...@finndesign.fi wrote:
Thanks to help, I'm now in the phase where I can kinit;aklog
succesfully as root/admin to the new domain, but I can only see the
directory structure, and not access either the existing /service or
On Tue, 24 Sep 2013, Andrew Deason wrote:
I doubt that they both can be online as afs servers simultaneously,
though.
You can't run an old and new server on the same machine from a
single IP address, that's true. But you _can_ just run the old server,
and point the old and new CellServDB
On Tue, 24 Sep 2013 11:56:29 +0300 (EEST)
Jukka Tuominen jukka.tuomi...@finndesign.fi wrote:
Thanks to help, I'm now in the phase where I can kinit;aklog
succesfully as root/admin to the new domain, but I can only see the
directory structure, and not access either the existing /service or
On Tue, 24 Sep 2013 14:45:57 -0400 (EDT)
step...@physics.unc.edu wrote:
You can't run an old and new server on the same machine from a
single IP address, that's true. But you _can_ just run the old
server, and point the old and new CellServDB entries at it, and it
looks like two different
Gotcha. I guess I hadn't followed Jukka's message closely enough. I thought
he had already set up a new cell and you were referring only to changing
fileservers. I see the bit about CellServDB now, so the non sequitur is
mine.
On Tue, 24 Sep 2013, Andrew Deason wrote:
On Tue, 24 Sep 2013
On Tue, 24 Sep 2013 22:12:52 +0300 (EEST)
Jukka Tuominen jukka.tuomi...@finndesign.fi wrote:
This time I destroyed the old krb data and created a new one. With
afs, I only replaced the old domains with new ones in conf files. I
did create the afs princ using different encryption if that makes
I was out sick yesterday, sorry I missed all the excitement.
On Mon, 23 Sep 2013, Andrew Deason wrote:
On Mon, 23 Sep 2013 09:08:35 +0300 (EEST)
Jukka Tuominen jukka.tuomi...@finndesign.fi wrote:
For Kerberos, if you're using about MIT or Heimdal, this may be
difficult, since usually the
On Tue, 24 Sep 2013 22:12:52 +0300 (EEST)
Jukka Tuominen jukka.tuomi...@finndesign.fi wrote:
This time I destroyed the old krb data and created a new one. With
afs, I only replaced the old domains with new ones in conf files. I
did create the afs princ using different encryption if that
On 09/24/2013 03:23 PM, Andrew Deason sent:
If you want to copy the data from a 'source' cell to a 'destination'
cell and you can have both available at the same time, you can use the
'up' tool to copy the directory tree while preserving all of the
afs-specific information and avoiding
On 9/24/13 15:50, Jukka Tuominen jukka.tuomi...@finndesign.fi wrote:
I understood the client pointing to two different domains with a single
destiny. I can also switch between the two servers (old and new) one at
the time, but I can't understand how the server can hold the two domains
at once.
On Tue, 24 Sep 2013 15:52:18 -0400
Todd Lewis uto...@email.unc.edu wrote:
I don't think 'up' will detect or avoid endless loops, but it's been a
while since I've been in that part of the code.
I meant to use it to copy individual volumes at a time (not traversing
mountpoints). That alone
I believe my script can create the mount points and acls (along with
krb/afs/ldap sync), and I can use the original user and group IDs. So, it
might be easiest if I'd recreate the service and homedir structure, and
transfer the contents either online or offline. Would that be the easiest
way?
On Tue, 24 Sep 2013 22:50:47 +0300 (EEST)
Jukka Tuominen jukka.tuomi...@finndesign.fi wrote:
That shouldn't be the problem here. What actual errors are you
seeing? Can you run 'fs lsm' on the things you can't seem to
access? (That is, 'services' and the homedirs)
'/afs/[domain]/service'
On Tue, 24 Sep 2013 22:50:47 +0300 (EEST)
Jukka Tuominen jukka.tuomi...@finndesign.fi wrote:
That shouldn't be the problem here. What actual errors are you
seeing? Can you run 'fs lsm' on the things you can't seem to
access? (That is, 'services' and the homedirs)
Do you see anything in syslog, or 'dmesg | tail' on the client when you
try to access these?
Sorry, I need to switch back to the new server...
According to the syslog, the cause might be the ldap service which is
still somehow off sync, eventhough it is trying to contact the new domain.
On Tue, 24 Sep 2013 23:31:22 +0300 (EEST)
Jukka Tuominen jukka.tuomi...@finndesign.fi wrote:
Okay, I thought you meant they were just offline or something. If
that's the problem, then it probably is related to authentication;
it seems more like the authentication setup is broken, not
Do you see anything in syslog, or 'dmesg | tail' on the client when you
try to access these?
Sorry, I need to switch back to the new server...
According to the syslog, the cause might be the ldap service which is
still somehow off sync, eventhough it is trying to contact the new
On Tue, 24 Sep 2013 23:31:22 +0300 (EEST)
Jukka Tuominen jukka.tuomi...@finndesign.fi wrote:
Okay, I thought you meant they were just offline or something. If
that's the problem, then it probably is related to authentication;
it seems more like the authentication setup is broken, not
On Wed, 25 Sep 2013 00:37:19 +0300 (EEST)
Jukka Tuominen jukka.tuomi...@finndesign.fi wrote:
mkdir saids it cannot be done because it's readonly.
For a dir in /afs/.cell? Not /afs/cell, but /afs/.cell; that is,
/afs/.[new.domain]. Can you 'fs lsm' /afs/.[new.domain] ?
Oops!
On Wed, 25 Sep 2013 00:37:19 +0300 (EEST)
Jukka Tuominen jukka.tuomi...@finndesign.fi wrote:
mkdir saids it cannot be done because it's readonly.
For a dir in /afs/.cell? Not /afs/cell, but /afs/.cell; that is,
/afs/.[new.domain]. Can you 'fs lsm' /afs/.[new.domain] ?
Oops!
On Wed, 25 Sep 2013 01:07:26 +0300 (EEST)
Jukka Tuominen jukka.tuomi...@finndesign.fi wrote:
So yes, the authentication setup is broken. Are you using the
non-DES setup, and do you remember exactly what you did?
addprinc -policy service -randkey -e aes256-cts-hmac-sha1-96:normal
Andrew Deason adea...@sinenomine.net writes:
You need to extract the keys from the KDC to let the openafs servers
know about it, using 'ktadd' from kadmin. In the past with DES keys, you
used 'asetkey' to add the key to the KeyFile. With non-DES keys, you can
just use the extracted keytab
On Wed, 25 Sep 2013 01:07:26 +0300 (EEST)
Jukka Tuominen jukka.tuomi...@finndesign.fi wrote:
So yes, the authentication setup is broken. Are you using the
non-DES setup, and do you remember exactly what you did?
addprinc -policy service -randkey -e aes256-cts-hmac-sha1-96:normal
Hi Andrew and Russ,
On Sun, 22 Sep 2013 11:09:38 +0300 (EEST)
Jukka Tuominen jukka.tuomi...@finndesign.fi wrote:
I'm facing a major challenge. I'm trying to move a populated
OpenAFS/Kerberos/OpenLDAP installation under another domain name. The
IP address remains the same. Hopefully there
On Mon, 23 Sep 2013 09:08:35 +0300 (EEST)
Jukka Tuominen jukka.tuomi...@finndesign.fi wrote:
For Kerberos, if you're using about MIT or Heimdal, this may be
difficult, since usually the keys for user principals are all salted
with the realm name. In the past I believe doing this was
On Mon, 23 Sep 2013 09:08:35 +0300 (EEST)
Jukka Tuominen jukka.tuomi...@finndesign.fi wrote:
For Kerberos, if you're using about MIT or Heimdal, this may be
difficult, since usually the keys for user principals are all salted
with the realm name. In the past I believe doing this was
On 9/23/2013 3:06 PM, Jukka Tuominen wrote:
kadmin.local: ktadd -k /tmp/afs.keytab -norandkey -e des-cbc-crc:normal
afs/[server.name]. But that was my earlier attempt (see a few lines below
what I did), so it may be different when I follow your suggestions more
closely...
Please do not
Thanks, I would have missed that!
br, jukka
On 9/23/2013 3:06 PM, Jukka Tuominen wrote:
kadmin.local: ktadd -k /tmp/afs.keytab -norandkey -e des-cbc-crc:normal
afs/[server.name]. But that was my earlier attempt (see a few lines
below
what I did), so it may be different when I follow your
On Mon, 23 Sep 2013 22:06:16 +0300 (EEST)
Jukka Tuominen jukka.tuomi...@finndesign.fi wrote:
I first tried to dpkg-reconfigure krb server packages so I could
introduce the new domain, but it persisted to use the old domain
without asking a thing, so I manually replaced all old domains in the
On Sun, 22 Sep 2013 11:09:38 +0300 (EEST)
Jukka Tuominen jukka.tuomi...@finndesign.fi wrote:
I'm facing a major challenge. I'm trying to move a populated
OpenAFS/Kerberos/OpenLDAP installation under another domain name. The
IP address remains the same. Hopefully there is a way save the users,
Andrew Deason adea...@sinenomine.net writes:
For Kerberos, if you're using about MIT or Heimdal, this may be
difficult, since usually the keys for user principals are all salted
with the realm name. In the past I believe doing this was considered
impossible to do with existing code, but maybe
41 matches
Mail list logo
