Subject: logging in

From: Ken Gillett <[email-masked]>
Date: Wed, 13 Feb 2002 20:31:39 +0000

I've just replaced my previous (mandrake) 1.5.1.1 rpm with my own 
compiled version as I wanted to incorporate SLP registration. But...

I can no longer log in as anything other than guest. Everything I try 
says the password is incorrect.

I specified '--with-pam=/etc/pam.d' and '--with-shadow' when I ran 
configure and I have the guest, cleartxt (linked to pam) and also a 
new passwd uam. They are listed in netatalk.conf and nowhere else 
(not changed from before).

I also specified '--disable-ddp', but I can't see that as the problem.

My guess is it's something to do with differences to the uams for my 
compile from the mandrake rpm, but can someone give me a clue as to 
what the problem is? I'd really appreciate it.

Thanks.

BTW, the auto SLP registration works fine:-)
-- 

Ken  G i l l e t t

_/_/_/_/_/_/_/_/_/

---

From: Steve Freitas <[email-masked]>
Date: Thu, 14 Feb 2002 00:55:42 -0800

Please post the pertinent line from afpd.conf, as well as an "ls -l" of your
uams directory (etc/netatalk/uams). And what kind of client is trying to
login?

> configure

You shouldn't have to specify any of this, as the configure step takes care
of it.

> and I have the guest, cleartxt (linked to pam) and also a

If you're using .passwd files, then afpd.conf should specify uams_passwd.so.
If you want users to authenticate against your /etc/shadow file, then you
should specify uams_dhx.so.

> I also specified '--disable-ddp', but I can't see that as the problem.

This just eliminates DDP advertisements. You're correct that it will have no
effect.

Steve

---

From: Ken Gillett <[email-masked]>
Date: Thu, 14 Feb 2002 16:00:55 +0000

At 12:55 am -0800 14/2/02, Steve Freitas wrote:
>Please post the pertinent line from afpd.conf

The following is from netatalk.conf:-

AFPD_UAMLIST="-U uams_clrtxt.so,uams_guest.so,uams_passwd.so"

afpd.conf says:-

     -uampath <path>  Use this path to look for User Authentication Modules.
#		       (default: /usr/lib/netatalk/uams)

This is NOT where make install put things. That uses 
/usr/local/etc/netatalk but I can see nowhere that specifies this. Is 
it possible afpd's not finding any uams.

>as well as an "ls -l" of your
>uams directory (etc/netatalk/uams).

This is /usr/local/etc/netatalk/uams

lrwxrwxrwx    1 root     root           11 Feb 13 18:34 
uams_clrtxt.so -> uams_pam.so
-rw-r--r--    1 root     root        21746 Feb 13 18:34 uams_guest.a
-rwxr-xr-x    1 root     root          787 Feb 13 18:34 uams_guest.la
-rwxr-xr-x    1 root     root        26084 Feb 13 18:34 uams_guest.so
-rw-r--r--    1 root     root        33318 Feb 13 18:34 uams_pam.a
-rwxr-xr-x    1 root     root          779 Feb 13 18:34 uams_pam.la
-rwxr-xr-x    1 root     root        37076 Feb 13 18:34 uams_pam.so
-rw-r--r--    1 root     root        26966 Feb 13 18:34 uams_passwd.a
-rwxr-xr-x    1 root     root          794 Feb 13 18:34 uams_passwd.la
-rwxr-xr-x    1 root     root        31234 Feb 13 18:34 uams_passwd.so

>And what kind of client is trying to
>login?

Mac, OS 9.2

>You shouldn't have to specify any of this, as the configure step takes care

I thought that you needed to specify which uams you wanted to use 
(and other things) on the configure command line.

>should specify uams_dhx.so.

As you can see, the dhx uams has not been compiled, which is odd 
since I specified to use /etc/shadow when running configure.

I am very unclear when the uams ought to be specified. There is an 
option to specify these in netatalk.conf and in afpd.conf. What is 
the significance of the 2 places and why also what about the 
configure command line? Why not compile them all and make them all 
available to be chosen at run time, in one of the above files.

I did find that I didn't get guest login if i didn't include that in 
the netatalk.conf uamlist, but I've not changed anything else since 
replacing the Mandrake rpm with my compiled version. It seems to me 
it could be related to paths since the source I used specifies 
different paths to Mandrake.
-- 

Ken  G i l l e t t

_/_/_/_/_/_/_/_/_/

---

From: Steve Freitas <[email-masked]>
Date: Thu, 14 Feb 2002 11:47:05 -0800

Ken,

Why don't you rip out the previous Netatalk installation and reinstall, and
this time do this:

[yadda@blah]$ ./configure --enable-redhat \
              --prefix=/usr/local/netatalk-1.5.1.1

Then make, make install, and see what happens. The way to tell whether afpd
has loaded the proper UAM is to do this command:

[yadda@blah]$ lsof | grep afpd

And see if the UAM you want shows up in the list.

> (and other things) on the configure command line.

I don't believe so. If Netatalk's defaults don't work, you need to specify
the back end authentication (like if you don't want to use PAM), but that is
all about the server side of the authentication, not the client side, which
is where the UAMs come in.

> available to be chosen at run time, in one of the above files.

That's what should have happened. And you shouldn't need to make any tweaks
at all after installation in order for DHX to work.

> different paths to Mandrake.

Did you uninstall the Mandrake RPM?

Steve

---

From: Ken Gillett <[email-masked]>
Date: Fri, 15 Feb 2002 09:42:09 +0000

>               --prefix=/usr/local/netatalk-1.5.1.1

Someone else is recommending I SHOULD use --with-shadow.

>[yadda@blah]$ lsof | grep afpd

Er, what's lsof?

>And see if the UAM you want shows up in the list.

I'd like to set in my mind how the uams work.

Setting the uamlist in netatalk.conf adds them to the command line 
when starting afpd. Am I correct to assume the effect is the same as 
specifying them in afpd.conf? It's a shame this isn't mentioned in 
the docs anywhere.

I found that if the guest uam was NOT listed in netatalk.conf guest 
access was disallowed. (I believe this change is mentioned in the 
1.5.1.1 docs)

What uams are required to logon to the netatalk server and get 
authenticated from the unix shell login:-

for that user?
for a guest?

How do you choose which authentication scheme to use anyway?

Shouldn't I specify --with-pam to ensure pam is used?

BTW, I used --with-pam=/etc/pam.d so if configure had assumed this to 
be a prefix to its default of /etc/pam.d maybe that's why it ended up 
in /etc/pam.d/etc/pam.d?

How come the uams directory that resulted from my compile included .a 
and .la files for each uam (that it bothered to make) as well as the 
.so, whereas the mandrake rpm only has (all) the .so files?

What is a utility like Timelord doing bundled with netatalk?

I have a lot of loose ends that I'd like to tie up:-)
-- 

Ken  G i l l e t t

_/_/_/_/_/_/_/_/_/

---

From: Steve Freitas <[email-masked]>
Date: Fri, 15 Feb 2002 03:17:47 -0800

> Someone else is recommending I SHOULD use --with-shadow.

That is a redundant option in this case. During ./configure, Netatalk
automatically looks for a PAM installation. PAM handles authenticating
against shadow.

Trust me on this -- I tested extensively with the developers when they were
rewriting the configure script, and you actually need to specify very little
in your case.

> Er, what's lsof?

I'll teach you to fish:

[yadda@blah]$ man lsof

> specifying them in afpd.conf? It's a shame this isn't mentioned in

Netatalk is definitely in need of docs help. If you want to volunteer, many
would appreciate your efforts.

> authenticated from the unix shell login:-

First, you need DHX in order to authenticate against /etc/shadow. Assuming
that, keep reading.

So you'll notice, if you look in the UAMs directory, that there are two
kinds of DHX UAMs. One authenticates against PAM, the other (I believe)
against "passwd" files, which are files that are stored in each user's home
directory and contains their password in plaintext. The latter method ain't
recommended in most cases.

uams_dhx_pam.so is what is necessary to authenticate through PAM against
your /etc/shadow file, which is used by the Unix shell login.

Going through PAM is, in most cases, the most correct way to do things,
because if you decide to change how your system authenticates users (say you
switch to Kerberos or NIS), you only need to tweak PAM, and you won't need
to touch Netatalk.

> for a guest?

uams_guest.so

> How do you choose which authentication scheme to use anyway?

If I understand correctly, you set what UAMs are available for Netatalk's
use in netatalk.conf. Then you can edit which ones are actually used in
afpd.conf.

Netatalk defaults to PAM+DHX, unless told otherwise, which will authenticate
recent AppleShare clients in encrypted form against /etc/shadow in your
case.

> Shouldn't I specify --with-pam to ensure pam is used?

No need, as Netatalk's configure script looks for it automatically. Pay
attention when compiling from source. You should watch the status lines that
are printed after you run ./configure. You'll see that (with the switches I
recommended) it finds your PAM install, and doesn't do shadow configuration.
And the result is that it authenticates against your Unix passwords, which
are in /etc/shadow. Magic!

> be a prefix to its default of /etc/pam.d maybe that's why it ended up

You're probably right.

> .so, whereas the mandrake rpm only has (all) the .so files?

I don't know. The make install probably isn't quite as clean as it could be,
while the Mandrake packager did a little cleanup work. They do no harm in
being there, though.

> What is a utility like Timelord doing bundled with netatalk?

Apparently somebody thought it was a good idea.

Seriously though, Netatalk has always been more than just a fileserver. With
Timelord and papd (the print server), Netatalk's a full Mac server.

> I have a lot of loose ends that I'd like to tie up:-)

I'll say.

I don't mean to criticize, but I think you went overboard in trying to
configure Netatalk before you even got it working. A simple ./configure,
make, make install would've gotten you on your way, but you decided to go
hog wild with the configure options, and that confused things for you.

The rule is, when you're installing from source, first get it working in the
simplest manner possible, and *then* tweak it to death.

Steve

---

From: Ken Gillett <[email-masked]>
Date: Fri, 15 Feb 2002 15:14:04 +0000

>rewriting the configure script, and you actually need to specify very little

I wasn't doubting you, just explaining the source of some of my confusion.

>[yadda@blah]$ man lsof

"No manual entry for lsof"

Trust ME on this one Steve, I wouldn't have asked without at least 
trying that. I've also done a find on the whole HD and there's no 
reference to this whatsoever. Maybe I missed something, but I tried 
the obvious that I could think of and came to the conclusion that 
it's not there.

BTW, I hate fishing:-)

>use in netatalk.conf. Then you can edit which ones are actually used in

All the uam stuff in afpd.conf is commented out, yet it certainly 
uses the guest uam specified in netatalk.conf and I guess the 
cleartxt one too. So I still don't get the relationship between these 
instances.

>simplest manner possible, and *then* tweak it to death.

I did, I used the mandrake rpm which got me up and running quite 
quickly. But, no SLP support which I wanted so I HAD to compile my 
own - no option. At this time I was instructed by others to pay 
attention to the configure options, rather surprised that so much 
configuration was required, but apparently it was necessary. It is my 
intention anyway to get acquainted with all the servers I am running, 
sufficiently well to compile them all myself. Hence my desire to 
learn about netatalk (and others).
-- 

Ken  G i l l e t t

_/_/_/_/_/_/_/_/_/

---

From: Steve Freitas <[email-masked]>
Date: Fri, 15 Feb 2002 12:11:06 -0800

> the obvious that I could think of and came to the conclusion that

Ahh. If you don't have lsof installed on your system, I understand why you
wouldn't have a man page for it. But you didn't mention that, so I'd assumed
your lsof package was just put together by a lamer. :-)

lsof: "List Open Files." It lists any open files, sockets, etc., by
processes. Enormously handy. When your server's been up for six months and
all of a sudden starts behaving utterly bizzarely, and you don't want to
surrender and reboot, lsof can tell you that one of your Apache modules has
gotten sloppy and isn't closing files, and it's run you clean out of file
descriptors. True story -- Unix doesn't like that.

You should have it on every *nix box you run. In this case, it can tell you
which UAMs afpd has open.

> cleartxt one too. So I still don't get the relationship between these

I'm a bit fuzzy on the relationship myself. I just use Netatalk in its
default config, with the exception that I comment the guest UAM line in
netatalk.conf so guest logins are off. Is your line commented?

For authentication, DHX is the default, but Netatalk also defaults to fall
back to cleartext for a client that doesn't support DHX.

Steve

---

From: Ken Gillett <[email-masked]>
Date: Sat, 16 Feb 2002 10:43:34 +0000

At 12:11 pm -0800 15/2/02, Steve Freitas wrote:
>...

OK, just got it, looks great, really useful. Had never heard of it 
before, now I have:-)

Thanks.

>netatalk.conf so guest logins are off. Is your line commented?

No, I want guest access to some shares.

>back to cleartext for a client that doesn't support DHX.

I would guess that netatalk.conf specifies the overall list of uams 
available and afpd.conf allows you to specify uams by server, so you 
can have different auth for different servers. Just my guess though.

BTW, the uams I compiled are several times larger than those that 
came with the mandrake rpm. Since it ought to have been the same 
actual source used for these how can they end up so different in size?
-- 

Ken  G i l l e t t

_/_/_/_/_/_/_/_/_/

---

From: Thomas Kaiser <[email-masked]>
Date: Mon, 18 Feb 2002 14:45:17 +0100

> AFPD_UAMLIST="-U uams_clrtxt.so,uams_guest.so,uams_passwd.so"

The first two entries are okay. The latter one is illegal, as you have to
specify types of AFP authentication and not to choose between backends, that
do the server side stuff (take a look into doc/CONFIGURE or use this html
version: <http://users.phg-online.de/tk/netatalk/doc/CONFIGURE.html>)

So this line should be read as:

AFPD_UAMLIST="-U uams_clrtxt.so,uams_guest.so"

as the last entry will be ignored.

As you specify these entries in netatalk.conf, they will be used for the
standard server in afpd.conf.

> it possible afpd's not finding any uams.

Take a look into your syslog. Afpd loggs the UAMs it uses/misses at startup
time.

>> as well as an "ls -l" of your uams directory (etc/netatalk/uams).
> 
> 
> [...]

Okay. The only UAM you have is 'Cleartext Authentication', which tries to do
the authentication via PAM on the server.

> [...]

The configure checks for the pre-requisites of each UAM and tries to build
them all. You will need OpenSSL (and probably DES) for RandNum, 2-Way
RandNum and DHX to build.

If you put OpenSSL in a standard location, configure will detect this on its
own.

>>> new passwd uam.

The passwd uam does direct server-side authentication like looking into
/etc/passwd or /etc/shadow. Another alternative is uams_pam.so, which does
authentication via PAM. By changing the symlink for uams_clrtxt.so you can
choose which one to use. To avoid potential PAM-trouble I would do a 'rm
uams_clrtxt.so && ln -s uams_passwd.so uams_clrtxt.so' in the UAMs
directory.

>>> They are listed in netatalk.conf and nowhere else (not changed from before).

In netatalk.conf you can specify the UAMs that should be presented to
clients for the default server. In afpd.conf you can list several servers
and assign an individual list of supported UAMs for each entry. Watch you
syslog on startup what happens.

Obviously you can only use the UAMs that are built before. And in your case
this is only one (except guest login)

>> should specify uams_dhx.so.

AFAIK this isn't true.

Between an AFP client and an AFP server several UAMs can be used -- with
netatalk the following 'standard' ones:

- Cleartext
- No User authent (aka guest login)
- RandNum and 2-Way RandNum
- DHX

(for details about the differences and pros/cons take a look at:
<ftp://terminator.rsug.itd.umich.edu/unix/netatalk/archive/netatalk-admins-m
ail/0647.html>)

Cleartext and DHX can use different authentication backends like PAM or Flat
Files. The ones to use can be specified by the symlink to the backend
mechanisms, either uams_passwd.so or uams_pam.so. RandNum and 2-Way RandNum
(both handled by uams_randnum.so) are different as they need the users
password's in a special place.

> since I specified to use /etc/shadow when running configure.

DHX has nothing to do with shadowed passwords. DHX is just a strong
encrypted authentication method between an AFP client and server. The
backend on the server can be either /etc/shadow, /etc/passwd or PAM (and
with PAM nearly everything -- even a remote windows NT server, IIRC)

> the significance of the 2 places

See above.

> and why also what about the
> configure command line?

With recent netatalk versions you don't have to specify single UAMs, as
configure tries to build the standard ones automatically (I refer to
'standard' UAMs as to the ones, that are already built-in into recent
AppleShare Clients so there won't be a need for client-side UAM modules
inside the AppleShare folder inside the system folder of each mac)

> Why not compile them all and make them all

This _is_ the way, it already works ;-)

You should read the output of ./configure carefully or better redirect it
into a file, eg. with 'nohup ./configure ...'

Later, you can grep through the output file 'nohup.out' and search for eg.

    checking for SSL... /usr (enabling RANDNUM and DHX support)
    checking for main in -lcrypto... yes
    checking for main in -ldes... yes

> the netatalk.conf uamlist,

This is how it should work.

> but I've not changed anything else since replacing the Mandrake rpm with my
> compiled version.

And your compiled version doesn't include support for DHX and (2-Way)
Randnum. The 'Cleartext' UAM should use PAM but maybe that's setup
incorrectly. So I would try to let uams_clrtxt.so point to uams_passwd.so
and see whether this works.

BTW: Checking the pre-requisites for building netatalk can be done by
examining the specs file of the RPM, you used before.

Regards,

Thomas