[Nut-upsuser] UPSLog rotating

[Tuc at T-B-O-H.NET]

> > mv /var/log/ups.log ${DATEDDIRECTORY}/ups.log
> > kill -1 `cat /var/db/nut/upslog.pid`
> 
> This is awkward. Doesn't FreeBSD have 'logrotate'?
>
	Not standard, but available in ports.
> 
> > I get :
> >
> > Sep 17 10:57:20 valhalla upslog[81972]: could not reopen logfile 
> > /var/log/ups.log: Permission denied
> 
> What do you expect? 
>
	So, sorry, expect isn't part of any of this. ;)
>
> After startup (and opening the logfile), upslog 
> will drop privileges. See 'man 8 upslog'. I would be surprised if it 
> would be able to create a file in /var/log then.
>

	Yup, it mentions it. It also mentions :

LOG ROTATION
       upslog writes its pid to upslog.pid, and will reopen the  log  file  if
       you  send  it a SIGHUP.  This allows it to keep running when the log is
       rotated by an external program.
>
> > So I stop upslog, remove the file, and start it to get a
> > clean/fresh file. It shows me :
> >
> > -rw-r--r--  1 root  wheel  36 Sep 17 10:59 /var/log/ups.log
> >
> >
> > So I change my script to :
> >
> >
> > mv /var/log/ups.log ${DATADIRECTORY}/ups.log
> > touch /var/log/ups.log
> > chown root:wheel /var/log/ups.log
> > chmod 644 /var/log/ups.log
> > kill -1 `cat /var/db/nut/upslog.pid`
> >
> > but I'm still getting :
> >
> > Sep 17 10:59:48 valhalla upslog[82020]: Signal 1: reopening log file
> > Sep 17 10:59:48 valhalla upslog[82020]: could not reopen logfile 
> > /var/log/ups.log: Permission denied
> 
> Well, that last line pretty much says what is wrong, doesn't it?
>
	Why yes, yes it does. It says the exact same thing as it
said before. So it means starting the program from scratch its
fine that the file is owned by root:wheel, but WHILE its running
it isn't. So, effectively, the program is creating a file it 
can't reuse. As if its opening it BEFORE it drops privs, but
somehow when its HUP'd it doesn't have access anymore to the
file it actually opened. (Since a stop and then start multiple
times from /usr/local/etc/rc.d/nut_upslog doesn't cause the
same issue). So, it would seem, that the logic for the file
opening is happening before it sheds its immortal userid for
the safety and security of the rest of the world.
>
> > Any thoughts where I'm going wrong??
> 
> See above. You need to restart upslog or put the logfile in a place 
> where the user running upslog has write access.
> 
	Well, the user that runs upslog (root) does have access,
and as you see it created a great file. Its just that if its
SIGHUP'd the file stops being accessible. So, the answer is
that even though the program itself originally starts it
as root and the program logic opens the file it seems before
it setuid's, I should look into the Makefile from ports
and change the owner/group to what its set to for FreeBSD
ports, which is :

NUT_USER?=      uucp
NUT_GROUP?=     uucp

	Even though thats NOT what the program itself 
does under a FreeBSD ports startup. 

		Thanks!

			Tuc