Here is last snip of the ctl_mboxlist strace. Apparently it is waiting
on the server. But looking at a successful mupdatetest output the client
should write to the server -- then wait for another response. It looks
like deadlock both the client and server are waiting to read data but
the client should be sending data..
Stupid question how do I attach strace to mupdate on the server since it
forks??
close(5) = 0
open("/tmp/krb5cc_200", O_RDONLY|O_LARGEFILE) = 5
fcntl64(5, F_SETLKW64, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0},
0xbfffaed0) = 0
read(5, "\5\3", 2) = 2
_llseek(5, 982, [982], SEEK_SET) = 0
read(5, "", 4) = 0
fcntl64(5, F_SETLKW64, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0},
0xbfffb2e0) = 0
close(5) = 0
time(NULL) = 1037723894
gettimeofday({1037723894, 182021}, NULL) = 0
gettimeofday({1037723894, 182493}, NULL) = 0
open("/etc/localtime", O_RDONLY) = 5
fstat64(5, {st_mode=S_IFREG|0644, st_size=1279, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x40194000
read(5, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0"...,
4096) = 1279
close(5) = 0
munmap(0x40194000, 4096) = 0
select(5, [4], NULL, NULL, {0, 0}) = 0 (Timeout)
write(4, "A01 AUTHENTICATE \"GSSAPI\" {772+}"..., 808) = 808
time(NULL) = 1037723894
select(5, [4], NULL, NULL, {1800, 0}) = 1 (in [4], left {1799,
996030})
time(NULL) = 1037723894
read(4, "YIGMBgkqhkiG9xIBAgICAG99MHugAwIB"..., 4096) = 194
time(NULL) = 1037723894
time(NULL) = 1037723894
select(5, [4], NULL, NULL, {1800, 0}
Output from mupdatetest
S: * AUTH "PLAIN" "GSSAPI"
S: * OK MUPDATE "XXXXXXXXX" "Cyrus Murder" "v2.1.10" "(master)"
C: A01 AUTHENTICATE "GSSAPI" {772+}
YIICPwYJKoZIhvcSAQICAQBuggIu < long line snip>
S: YIGMBgkqhkiG9xIBAgICAG99MHu < long line snip>
C:
S: YD8GCSqGSIb3EgECAgIBBAD///// < long line snip>
C: YD8GCSqGSIb3EgECAgIBBAD///// < long line snip>
S: A01 OK "Authenticated"
Authenticated.
Security strength factor: 56
Rob Siemborski wrote:
>
> On Tue, 19 Nov 2002, Paul M Fleming wrote:
>
> > I'm trying to setup a test murder system and am having a problem with
> >
> > ctl_mboxlist -m
> >
> > I'm using GSSAPI. I'm getting the correct tickets because I can manually
> > run imtest and mupdatetest. I get authenticated to the
> > frontends/backends ok. I'm also able to proxy correctly (using imtest -a
> > authen name -u userid) When I attempt to run ctl_mboxlist -m it just
> > hangs. If I sniff the connection. i see the banner, the client requests
> > GSSAPI and sends the first message and then nothing.. syslog on the
> > mupdate host shows the start of the cmdloop but I never get through the
> > authentication phase -- never even get a auth failure message in syslog.
>
> You'll need to do better than "nothing happens". Have you tried getting a
> truss/strace of both the client and the server?
>
> > I also attempted to connect directly to the backend via cyradm and
> > create a mailbox. This hangs waiting for a mailbox reserveration. An
> > tcpdump shows the same gssapi as above -- it starts but never finishes..
>
> Well, yeah, since it will need to update mupdate before anything else
> happens.
>
> > Any ideas what I'm missing? Does ctl_mboxlist require a protection_layer
>
> Nope.
>
> > > 0? Has the mupdate-client code been testing with gssapi??
>
> Not vigorously enough, apparently ;)
>
> -Rob
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
> Research Systems Programmer * /usr/contributed Gatekeeper
