Tuesday, September 30, 2008

More Adventures with SME server and Friends

Yep - I'm still alive :-)

The spouse called me from home trying to send an email - and Thunderbird was telling her the mail server was temporarily unavailable, and she was on a deadline :-/

My first thought was to ssh in and try to send mail from my linux box on the LAN. Problem was, the DynDNS updater built into the SME server doesn't handle the possibility of being behind a NAT of it's own.

Instead I got her to turn on the LogMeIn service which is on that machine but always disabled, and I got in and started poking around. It was weird. I set up gmail as an smtp server and sent the message that way - which put the gmail account as the reply to on the message. Not a big problem since her gmail account (which she never uses) auto forwards to her 'real' POP account anyway, but an indication it was only a temporary fix.

Called the ISP, talked to first level support (much better than you'd expect - polite, friendly and helpful - gotta love my ISP!) who didn't have any insight into the issue and promised to get second level support to call me. They did - within about a half an hour, and we poked at it for a couple of minutes. Oddly, he couldn't see my attempts at sending an email show up at his end at all (he's watching the mail server logs as he's talking to me). He suggests swapping to port 587 and lo and behold it works fine. He's pretty convinced the problem is mine. I let him go and after a bit it comes to me - the SME server is blocking port 25 outbound I bet. Later on I prove it out

==> telnet smtp.myisp.com 25
Trying the.ip.of.that.server...
Connected to smtp.myisp.com.
Escape character is '^]'.
elo
220 mySMEserver.notTheISP.com ESMTP

So, while it was nice that LogMeIn got me in, I wanted to get remote ssh up and going again.

A quick google didn't reveal a fix for the built in DynDNS software (I didn't look very hard) so I grabbed ddclient from dyndns.org and followed the Red Hat installation instructions. Worked perfect first try. (If you know of an 'official' package to do this, by all means let me know)

It really points out both edges of the SME sword. If you use DynDNS the way most people do, then their prebuilt config is perfect - easy, helpful and exactly what you want. If you don't want that, you have to start working 'around' the software instead of with it. It's still RedHat, so it's not a big deal in this case, but it's a good example.

Next up I went to forward port 22 thru the modem, thru the SME to my personal linux box. Thru the SME server was easy. Thru that modem was not. I don't find that firewall config easy or intuitive, and I don't like a firewall I'm not comfortable with. I'm really reconsidering the setup.

Sunday, September 7, 2008

SME Server install

Just so you don't think I'm dead or something :-)

I installed SME server on that same box that eBox choked.

Even though SME suggests a minumum of 256 meg, it installed and so far is running fine on just 128. Now, I'm not using it for much more than DNS and a firewall at the moment, so I won't be suprised if it keels over when I add a few services, so far so good!

Here's some notes I made during the install. Kind of stream of consciousness stuff - hope it's at least somewhat understandable.


It has no config questions at all, not even partitioning, without passing options to kernel! Come to think of it - no questions about hostname or primary eth or anything!

I found out later (yeah I know RTFM!) that it does automatic software RAID. If you have two drives it does RAID 1, three drives RAID 5 and four or more drives RAID 6 - all on it's own. That seems to be kind of indicative of the way SME is done. It has a number of nice touches like that which are really neat if it's what you want, but a bit disconcerting if you want to do it all yourself.

Turns out that all the configuration happens *after* the install is complete and it runs a config stage.

First question on reboot was do you wish to restore from backup? Cool idea - hope it only happens on unconfigured box :-P

Second question is admin password. It didn't like my choice (which surprised me - it's over 8 characters and contains a mix of letters numbers and punctuation!) I tried a bunch of variations, and it didn't like any of them, including a really ugly sucker. There's got to be a bug there! Made a note to check on later. Oddly, it doesn't ask for an administrators username, just the password.

Again, after the fact I found out why. If you log in as 'admin' it puts you straight into an 'admin' console with predefined choices for reconfiguring, viewing system info etc etc. You have to log in as 'root' to get a real shell. Both users are set up with the same password.

Third question was server and gateway, private server and gateway or server only. Private means no WAN side services.

Dedicated network or dialup - cool option for those of us rural types that understand high speed networks aren't universal!

The next question was which eth card is which. In my case it correctly indicated that both cards (although different models) use the same driver. Good info, but then it gives you nothing to determine which card it thinks is which. It doesn't identify by model or MAC which is eth0. The options were labelled 'Normal' or 'Reversed' with eth0 marked as the local interface, I took a guess eth0 was the on board NIC and got lucky.

Next question is dchp or pppoe or static - has account name as identifier option for dhcp, or MAC address.

Next question is dyndns provider if desired - cool! Prompted for details including password. In my case it's not working :-( It's probably because it's 'WAN' interface is behind the modem we reconfigured as a NAT router. As a result the WAN IP is still a private network IP, and DynDNS probably rejects those. I didn't see anyway to tell it to use an alternate script or whatever to determine the proper IP address using the provided web interface or admin console. It's probably easy enough to change directly in the /etc config info - I'll just have to go looking.

Next question is dhcp on lan yes or no and range of numbers to provide.

Next question is specified DNS server or not, with the note that you shouldn't use your ISP's DNS server as it's not required. It made me wonder if SME server has the updates for the DNS issues that were big news last month. Another note to go look for stuff....

Save config and it 'activates changes' which looks like changing run-levels.

Noticed 'activating Smolt weekly checkin' - Google shows
Smolt is developed to collect hardware profiles from end users in a opt-in method.


Now I know how SME server has such good user stats. I bet if I read the install manual I'd get the 'opt in' option somehow too :-)

On the whole, it's really a predetermined design, the admin just fills in the blanks.

I had to finally read the manual to get to the web interface. Turns out the default apache page is just an 'under construction' banner, while the management page is at hostname/server-manager/

Not sure if that's an attempt at security thru obscurity...

I also noted the hardware requirements mentioned there are minimum 400Mhz and 256 meg of ram, recommended 1.5Ghz and 512Meg. It's running OK with just 128 so far though!

As it stands, I've configured static IP address thru DHCP (fixed leases) and set host names for all the devices on my LAN. It's a straight forward operation using the web interface, but a little clunky since there's no easy way to get the MAC address from the interface to plug back into the interface. IPCop has a nice option to turn a regular DHCP lease into a fixed lease which means you don't have to resort to cut and paste between an ssh session and the web interface.

I've had a couple of small issues, most of them self inflicted. One of my ethernet cables has a broken lock tab, so it was on the edge of connecting or not connecting depending on how it felt - even though it looked fine.

I also found out that running downloading a couple files via bittorrent seems to completely saturate my (fairly anemic) upstream. It got so bad that DNS wasn't resolving before the PCs gave up trying, so it looked like everything was down, when in fact it was just really really slow. I had some really simple traffic shaping set up on the IPCop box - looks like I'll have to see about adding that to SME as well. I see there's a plugin for it available in the contrib section which is promising.

One other frustration has been the modem as gateway. It works, but that interface is clunky and confusing. I haven't quite decided what to do about that yet.

SME server is certainly a solid solution for a small LAN - especially if you want to leave it in the hands of say a 'Windows Power User'. It's been designed to be easy to use, while retaining some powerful features.

All in all, this blog really hasn't worked out as intended - I figured I'd have the time to get this setup way way down the road from where it's at now. With a busy fall looming, don't expect me to get back to daily entries soon, but I am carrying on, even if it doesn't seem like it.

Before I go on to hardware that eBox and Ubuntu will run well on, I'm going to at least fix DynDNS, install Dan's Guardian or similar and some traffic shaping on the SME server and see how that plays out.

128meg Just Won't Cut It

I installed eBox on the guinea pig a couple of days ago, but didn't proceed to configuration or anything, just left it sitting at the log in prompt.

Here's what I noticed from the installation process.

First off, the eBox CD gives no indication it isn't an Ubuntu CD. I think it's worth a couple of minutes of somebody's time to stick the eBox logo on it, and add a couple of words of text somewhere indicating it's not just a vanilla Ubuntu install CD. I'll have to investigate the eBox bug tracking system at one point and make that suggestion.

In what's likely a related issue, the media check process on the CD fails when you try it. I'm *guessing* that when the eBox project added the eBox installation scripts, they didn't update the media checking function, so it's failing because of the extras. I didn't confirm this, but the installation did proceed ok - so either the media issue is subtle or in an area I didn't use, or my guess is on the mark. Kinda disappointing in a 'fit and finish' kind of way - but not a big problem. (note to self - did I even check the md5sum on the iso?)

I didn't preplan the partitioning, so when I reached that section I was flailing around a bit. I did have a couple of 'huh?' moments, but from past experience with the Ubuntu alternate CD I know that you can get the partitioner twisted up a bit if you flip back and forth between LVM and RAID etc etc and don't approach it in a logical fashion.

The game plan was a 256meg /boot with the rest on LVM. On the LVM I had a swap partition of 768meg (overkill, I know, but I knew this machine would need swap) and the rest in /. I figured the file share for clients would be on it's own partition I'd set up later. Looking back afterwards, I was kicking myself for not at least putting /var/log on a separate partition, but I could 'fix that in the mix'
as they say.

There were no options to the rest of the install really, just pick which ethernet card was primary, time zone, keyboard etc. I kept waiting for questions but they never came.

On reboot I was struck with just how long the reboot was taking. It seemed to take forever (no, I didn't time it...) Some of it was one time only stuff like generating RSA keys, but I was thinking to myself it wasn't looking very spouse friendly. She'd expect it to be working by the time her client PC booted back up - or at least close to it - not sitting around waiting for a server that she only vaguely remembers is there to complete doing something she can't even see. I was reconsidering my limited RAM machine at this point.

There were two errors during that initial boot. One was Dan's Guardian failing to start up, with a comment about editing the config file. Made sense, since I hadn't configured anything to do with
saslauthd is a daemon process that handles plaintext authentication requests on behalf of the SASL library.


None the wiser, I made a note to look into that further too. :-)

I also see from my scribbed notes I saw mention of Quagga, but I didn't make a note as to why I made a note about Quagga!

Googling quickly about again, it looks like Quagga is related to routing, probably BGP stuff or similar.

The installation didn't take that long, but I was out of time, so I left it sitting at the log in screen with my notes.

When I came back to it this morning, I was met with a screen full of error messages about killing apache processes due to lack of ram :-( I guess that's that.

So, I've reached a couple of conclusions.

1 - Hardy + eBox = more than 128 meg of ram required

2 - I was disappointed with the lack of choice during the install. Maybe it was a good way to get the flavour of an eBox set up, but it went against the grain of an old knob twister like me. Next time I think I'll do the eBox install the Ubuntu way - install from a vanilla server CD, and add the eBox packages afterwards.