[[APi]TheMan]

I've begun to notice that after running a system for a few days (and up into times of several weeks) without restarts, uptime checks seem to return weird results.

I seem to get a rather long list of entries such as:

"uptime: /dev/ftp597: No such file or directory"

Not that it affects functionality, but it's strange.

[Detrius]

try
which uptime

[[APi]TheMan]

Originally posted by Detrius:
try
which uptime

What for? The uptime command works... I just get a strange result after I've been running for a few days

Code:
[aorth@ssku225-174-c: ~]$ which uptime 
/usr/bin/uptime

[[APi]TheMan]

Here's an example:

Code:
[aorth@ssku225-174-c: ~]$ uptime
uptime: /dev/ftp24506: No such file or directory
uptime: /dev/ftp18583: No such file or directory
uptime: /dev/ftp18594: No such file or directory
uptime: /dev/ftp18616: No such file or directory
uptime: /dev/ftp18627: No such file or directory
11:03  up 5 days, 20:25, 3 users, load averages: 1.54 1.57 1.44

What gives?

[Moonray]

Perhaps something messed with your /var/run/utmp file. Try:

Code:
sudo mv /var/run/utmp /var/run/utmp.1
sudo touch /var/run/utmp
uptime
sudo mv /var/run/utmp.1 /var/run/utmp

If you don't get these messages now, find out what changes that file. Probably something FTP related.

-

[[APi]TheMan]

Originally posted by Moonray:
Perhaps something messed with your /var/run/utmp file. Try:

Code:
sudo mv /var/run/utmp /var/run/utmp.1
sudo touch /var/run/utmp
uptime
sudo mv /var/run/utmp.1 /var/run/utmp

If you don't get these messages now, find out what changes that file. Probably something FTP related.

I just came back here to post that I noticed that the number of lines of ftp gibberish returned before the actual uptime is returned is the same amount of times that I've logged into my system via FTP.

If I reboot and run uptime there will be no ftp gibberish messages. If I log in via ftp three times and then check the uptime, there are three lines of "file or directory not found" messages.

Odd. I'll try playing with the temp files, thanks.

edit: Deleting /var/run/utmp and touching a new one fixes the strange return until I log in via FTP again. Very odd but good to know how to clear out the return somewhat. Thanks for pointing me in the right direction, Moonray.

[[APi]TheMan]

Hmm, a little poking around and this is what I found in /etc/xinetd.d/ftp:

Code:
service ftp
{
        disable = no
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/libexec/ftpd
        server_args     = -luw
        groups          = yes
        flags           = REUSE IPv6
}

Most importantly the server_args, of which the -u is the culprit. From ftpd's man page:

Code:
     -u      Log each concurrent FTP session to /var/run/utmp, making them
             visible to commands such as who(1).

Also, I noticed that if I use who to see who is logged in I get a list of both shell users and ftp users, which is the desired effect. If I use w I get the strange /dev/ftpsome_number return before the desired return. Very strange, as both who and w use /var/run/utmp for their output.

[Moonray]

Obviously the users don't get properly removed. I understand utmp more as a database holding current users than a log file. But you know how to help yourself now .

-

[[APi]TheMan]

Originally posted by Moonray:
Obviously the users don't get properly removed. I understand utmp more as a database holding current users than a log file. But you know how to help yourself now .

-

Yah, I did do my homework on this one I guess. I hope you learned a little something through this too. Thanks for your input, though, maybe someone will find this thread petrified in some few years in the future and we'll be put in some museum.

[Moonray]

Yes, I learned to stay with ProFTPD which does not try to utilize system stuff for its needs and comes with a 'ftpwho' to shows who's on the FTP

(Carving in 'Moonray was here 01-22-2004')

-

[[APi]TheMan]

Originally posted by Moonray:
Yes, I learned to stay with ProFTPD which does not try to utilize system stuff for its needs and comes with a 'ftpwho' to shows who's on the FTP

(Carving in 'Moonray was here 01-22-2004')

-

ProFTPD? So I've heard. Pre-10.3 when Mac OS X's ftpd had a malfunctioning chroot I considered making the switch to ProFTPD, and since then I've tried to get it up and running a few times but I always seemed to get caught up somewhere. This time I got everything compiled and I actually read the INSTALL file where it suggested testing the service before installing. The test went well and I tested a few of ProFTPD's companion programs as well with much success (ftpwho mainly).

So I decided to install it. I had to do a little tweaking (changing the manpath to include ProFTPD's manpages and turning Mac OS X's ftpd off), but now when I log in it gives me a login error. What gives?

Code:
Name (127.0.0.1:aorth): aorth
331 Password required for aorth.
Password:
530 Login incorrect.
ftp: Login failed.

Do I have to specify a passwd file for it to use? Also, how important is the part of the config that tells which user and group for the server to run as? I told it to run as root and wheel, respectively.

[Moonray]

I installed it in 10.0 times and it runs flawlessly since then, so I hope I remember correctly:

• Mine does run on some high port and is not started by inetd (conf: ServerType standalone, Port xxxxx). I start mine in /etc/ppp/ip-up.
• Running it as root:wheel isn't a good idea for security reasons. The original default (I think it was nobody:nobody) didn't work first for OS X because Apple used negative numbers for them (that's fixed now I think), so I chose something else. If you have a user ftp and a group guest or something that will work fine.
• The ability to use an own user database was a big advantage for me so no ftp account can accidentally get a login account (conf: AuthUserFile /usr/local/etc/ftpd.passwd, AuthGroupFile /usr/local/etc/ftpd.group. Any other path is fine too of course. There is a perl script ftpasswd that helps creating the ftpd.passwd file). Using the original passwd files/mechanisms is also possible on normal Unix systems, I'm not sure about integration of OS X's netinfo yet.

Hope that helps.

-

[[APi]TheMan]

Mine does run on some high port and is not started by inetd (conf: ServerType standalone, Port xxxxx). I start mine in /etc/ppp/ip-up.

I don't plan on starting mine by inetd but I plan on using the standard FTP port. I guess the reason I thought I needed ProFTPD to run as root:wheel was because I thought Mac OS X's ftpd ran as root. Now that I check it runs as my user. I guess it didn't make sense to me that proftpd should run as any user other than root because it wouldn't be able to access any directories outside of that user's ~. Example: If I ran it as user test, then user test2 logs in and proftpd cannot get into test2's home directory. Is this handled by the user authenticating with the system when he logs in, thus allowing him to access his folders?

The ability to use an own user database was a big advantage for me so no ftp account can accidentally get a login account (conf: AuthUserFile /usr/local/etc/ftpd.passwd, AuthGroupFile /usr/local/etc/ftpd.group. Any other path is fine too of course. There is a perl script ftpasswd that helps creating the ftpd.passwd file). Using the original passwd files/mechanisms is also possible on normal Unix systems, I'm not sure about integration of OS X's netinfo yet.

Ah, I was wondering about that. I figured that proftpd would just default to using /etc/passwd, but this isn't so? I tried to specify /etc/passwd for my AuthUserFile and I was not able to authenticate, unless I did something wrong. Also, what's the use of the AuthGroupFile? Is that for group passwords (which, as I understand, I don't want)?

Thanks for the pointer on the ftpasswd, it worked like a charm; it worked like a charm and I got myself authenticating very quickly.

edit: I just read /etc/passwd and found this:

Code:
# This file is used while in single user mode.
#
# To use this file for normal authentication, you may enable it with
# /Applications/Utilities/Directory Access.

I don't know why I didn't read that in the first place. I guess on traditional Unix systems /etc/passwd actually has users' passwords in them, I did notice that /etc/passwd on Mac OS X really doesn't contain passwords for anything useful, only boring system daemons and stuff.

[Moonray]

Originally posted by [APi]TheMan:
I don't plan on starting mine by inetd but I plan on using the standard FTP port. I guess the reason I thought I needed ProFTPD to run as root:wheel was because I thought Mac OS X's ftpd ran as root. Now that I check it runs as my user. I guess it didn't make sense to me that proftpd should run as any user other than root because it wouldn't be able to access any directories outside of that user's ~. Example: If I ran it as user test, then user test2 logs in and proftpd cannot get into test2's home directory. Is this handled by the user authenticating with the system when he logs in, thus allowing him to access his folders?

Oh, you start it as root, but have these lower privileged users in the conf file. It will start child processes with the ID of the user logging in so everyone can access the own home directory. This works for users that are real existing users as well as for those that have only a ProFTPD password entry. (I was slightly wrong about "running it" in my previous post).

Ah, I was wondering about that. I figured that proftpd would just default to using /etc/passwd, but this isn't so? I tried to specify /etc/passwd for my AuthUserFile and I was not able to authenticate, unless I did something wrong. Also, what's the use of the AuthGroupFile? Is that for group passwords (which, as I understand, I don't want)?

On Mac OS X there is no user login information in /etc/passwd, the users and passwords are stored in the netinfo database. There are tools to export the data (niutil something) but I think it's easier to build a new one, also exporting the passwords might be a problem.
And yes, you don't want group passwords, just use a copy of /etc/group or point directly to it. (If you assign groups to your users you can use groups permissions for these users as well).

Thanks for the pointer on the ftpasswd, it worked like a charm; it worked like a charm and I got myself authenticating very quickly.

I wrote even another script to call this one.

edit: I just read /etc/passwd and found this:

Code:
# This file is used while in single user mode.
#
# To use this file for normal authentication, you may enable it with
# /Applications/Utilities/Directory Access.

I don't know why I didn't read that in the first place. I guess on traditional Unix systems /etc/passwd actually has users' passwords in them, I did notice that /etc/passwd on Mac OS X really doesn't contain passwords for anything useful, only boring system daemons and stuff.

Yes, see above. I didn't know that there was the ability to enable this file now, but normal Unix systems have nowadays shadow passwords and nifty stuff so enabling this might make things a bit less secure because this file is world readable and an intruder might try a brute-force attack on the encrypted passwords therein. Furthermore having comment lines in /etc/passwd like Apple does has always been seen as a security risk because passwd(1) might change such lines to entries that allow root logins without password. Even if that's fixed now it does not feel good to see that.

-

[[APi]TheMan]

Moonray... I'm having trouble getting proftpd to run via xinetd.

Code:
service ftp
{
        disable = no
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/local/sbin/proftpd
        server_args     = -c /usr/local/etc/proftpd/conf
        log_on_success  = HOST PID
        log_on_failure  = HOST RECORD
        instances       = 50
        bind            = xxx.xxx.xxx.xxx
        flags           = REUSE IPv6
}

That's my /etc/xinetd.d/ftp (I backed up the original), it's kinda over-involved and I'd be fine with trimming it down because I know it should run fine with a slimmer set of commands in there.

One thing to note, I did change "ServerType" to inetd in my config file, so I'm not exactly sure what is next. That's the only thing I know that is necessary, all those other settings in the xinetd ftp config file were just frills that I'm sure I don't need.

Whatcha think?

[Moonray]

I think it should run, for proftpd there's nothing else to change than the server type. I run it in standalone mode so i can't say which xinetd settings would work for me.

When you try to connect, xinetd should start a proftpd process, you won't see it running before. Do you see any error messages?

-

[[APi]TheMan]

Ah-hah! I got proftpd to run via inetd in Panther... Yes, I mean inetd. I wasn't getting any errors to stdout, maybe they were headin' out to stderr? Who knows, but I got proftpd working. Here's what I did...

I noticed that xinetd was running with the -inetd_compat flag which, the xinetd manpage says:

Code:
-inetd_compat
              This option causes xinetd to read /etc/inetd.conf in addition to
              the standard xinetd config files.  /etc/inetd.conf is read after
              the standard xinetd config files.

So I changed the ftp line in /etc/inetd.conf and killed xinetd with: sudo kill -HUP `cat /var/run/xinetd.pid` and voila!

The only reason I wanted to get it running through inetd/xinetd was because I forget very easily to restart standalone daemons unless they're started automatically. I'm sure I would have ended up writing some startup script, who knows, but this works... even if it is kindof a workaround.

Thanks, Moonray, even though you were just here for moral support pretty much. :-D

(oh, the only reason I take the time to fully explain everything in much more detail than you, a competent computer user, would need is because I'm sure someone will be searching google or these forums for this problem 2 years from now... and all these keywords and complete answers help... I know you know what I mean.)

[Moonray]

Okay, congrats that it works now .. and all that started with a strange uptime return.

(For those future readers: You know though that sudo kill -HUP `cat /var/run/xinetd.pid` rather causes xinetd to re-read its configuration file(s) than kills it as in terminating it).

-