# Headless, internetless server installation



## PeteS (Dec 30, 2010)

I've installed FreeBSD 8.1 on a system that will do one thing only - ntp server.

It uses an SSD disk, is completely headless and the case has no physical access to usb or any other connections besides ethernet. 

It will be running 24/7/365 and it will only shutdown (unclean) by a power failure.
It wont be able to access internet. And it will only be administered if it doesn't work and then remotely via ssh or by shipping it to me.


1) Do I need to change anything on a standard installation so it doesn't need any attention?

2) Are there any log files that will grow big over time (SSD is 40GB)?

3) Do I have to change anything for the SSD (speed is not an issue, only unclean shutdowns)?

4) Do I need to do anything to sendmail? Obviously no mail will be delivered anywhere.



Thanks in advance for any help or pointers to things I haven't considered.

Pete S


----------



## wblock@ (Dec 30, 2010)

Depending on what you're doing for status reports, you might want to use sendmail_enable="NONE".  cron job output can build up, though.


----------



## PeteS (Dec 30, 2010)

wblock said:
			
		

> Depending on what you're doing for status reports, you might want to use sendmail_enable="NONE".  cron job output can build up, though.



There don't seem to be any cron jobs running in the default installation though? So it would be only cron jobs of my own doing that could build up logs. Is that a correct assumption?


```
for user in $(grep -v \# /etc/passwd | cut -f1 -d: ); do crontab -u $user -l; done
crontab: no crontab for root
crontab: no crontab for toor
crontab: no crontab for daemon
crontab: no crontab for operator
crontab: no crontab for bin
crontab: no crontab for tty
crontab: no crontab for kmem
crontab: no crontab for games
crontab: no crontab for news
crontab: no crontab for man
crontab: no crontab for sshd
crontab: no crontab for smmsp
crontab: no crontab for mailnull
crontab: no crontab for bind
crontab: no crontab for proxy
crontab: no crontab for _pflogd
crontab: no crontab for _dhcp
crontab: no crontab for uucp
crontab: no crontab for pop
crontab: no crontab for www
crontab: no crontab for nobody
```


----------



## wblock@ (Dec 30, 2010)

Well, there's /etc/periodic.  That creates the two-per-day status reports.


----------



## PeteS (Dec 31, 2010)

wblock said:
			
		

> Well, there's /etc/periodic.  That creates the two-per-day status reports.



OK, thanks. I found that they are executed from periodic in /etc/crontab.

If I set sendmail_enable="NONE" where will reports from daily/weekly/monthly end up? Nowhere?


----------



## DutchDaemon (Dec 31, 2010)

It's probably easier to put this in /etc/mail/aliases and leave Sendmail alone:


```
root:        /dev/null
```


----------



## PeteS (Dec 31, 2010)

DutchDaemon said:
			
		

> It's probably easier to put this in /etc/mail/aliases and leave Sendmail alone:
> 
> 
> ```
> ...



Would it be equally effective changing /etc/mail/mailer.conf to point to a script instead of the sendmail executable?

In that case I could have the script save the emails in files that I could then erase as they got old. Any program executing sendmail would be happy and I'd have the opportunity to look at any mails. And I wouldn't need to run sendmail at all. 

Or is that a stupid idea?


----------



## DutchDaemon (Dec 31, 2010)

You can also pipe mail to a script in /etc/mail/aliases, or by using mail/procmail.


----------



## wblock@ (Dec 31, 2010)

You can also adjust things in periodic.conf(5).  But piping the output to a script and then saving those reports... that's what the daily status reports do already.  Then they mail it to root, or to another local user, or save them to log files (see the man page above).


----------



## PeteS (Jan 3, 2011)

OK, I think I have it working now. Besided disabling sendmail startup I had to configure periodic to not output to mail and also disable all sendmail related cleanup. I also disabled mail in crontab for god measure.

I decided to go that route because it seemed more logical to not have sendmail running at all from a resource, security and configuration point of view.


----------

