Posts Tagged ‘sme7’

Troubleshooting “server-manager” in SME Server

Friday, November 19th, 2010

Originally this post was going to document my troubleshooting of my login problem with the web based administrative interface of SME Server 7 after my bare (virtual) metal restore. In the end, I gave up fixing the problem, and did the upgrade via CD to SME Server 8 beta 6.  This didn’t turn out to be an easy fix, and I also had my eye on some nice benefits to upgrading to SME8, such as PHP5 and MySQL5 (finally!)

The following now serves as a review of how I think the “server-manager” interface is delivered in SME’s architecture.  It’s elegant, but complex.

The exact error was:

You don’t have permission to access /server-manager on this server.
Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.

Unfortunately, I just didn’t know how to troubleshoot this error.  A lot of the problem was that SME is more complex than your normal web server do to  security precautions.

This is how I think the “server-manager” GUI is hosted:

  • You normally go to (or whatever your server’s local IP is)
  • The web server, “httpd”, which runs as user www and group www (which I assume has minimal permissions) then reverse proxies to a second httpd process, httpd-admin
  • The second Apache server, httpd-admin, runs on port 980, and runs as user admin and group admin.
  • The 2nd web server has it’s own configuration files.
  • The web scripts are in this folder: /etc/e-smith/web/panels/manager/
  • On a fresh install, the Linux admin user is group id 101, and the admin group is id 101 (my restored server had a different group id)

Increasing the Drive Space of an SME Server – a crash course in LVM

Thursday, November 11th, 2010

My adventurous rebuild of my home server continues.

I made a mistake when rebuilding my VMWare Server virtual machine, I used the default 8GB partition size, which is too small, even though it only holds work files for a couple of users.

I had most things back up and running, so it was time to fix my disk space error.  This turned into a crash course in Logical Volume Manager (LVM).

DISCLAIMER: I take no responsibility for any actions that you take on your own systems.  As I mentioned, this is all new to me, and it is very possible that I have made mistakes. Follow at your own risk. I’m not even sure that I have all the terminology correct.

The following are somewhat edited  notes that I took as I went along.

First, some terminology, mostly from:

  • LVM abstracts disk space as seen by the operating system from physical disks.
  • A Volume Group is the highest level abstraction used within the LVM. It gathers together a collection of Logical Volumes and Physical Volumes into one administrative unit. (This is an extra level of organization than you might be used to… you might put all SSDs in one VG and all HDDs in a separate one to make it easier to keep track.)
  • A physical volume is typically a hard disk, though it may well just be a device that ‘looks’ like a hard disk (eg. a software raid device).
  • LV = Equivalent of a disk partition in a non-LVM system. The LV is visible as a standard block device; as such the LV can contain a file system (eg. /home).

General overview:  Create disk space in VMWare (or add physical disk space in a non virtualized environment).  Create a new partition. Join that partition to a Logical Volume to make the Logical Volume larger. Expand the Linux partition to fill it’s now bigger Logical Volume.

The steps that I took:

  • Expand the VMWare virtual disk with the VMWare tool (Google for it).  The non-VM equivalent would be to clone an old, smaller drive onto a new, larger drive.
  • create a new disk partition on the VMWare “physical” disk.
    • /sbin/fdisk /dev/sda
    • n [new]
    • p [primary – I wonder if E would have been a better long term choice]
    • 3 [I think there are two already]
    • defaults for size
    • w [write]
    • /sbin/shutdown -r now
  • create the physical partition (LVM)
    • /sbin/pvcreate /dev/sda3
  • that worked:
— Physical volume —
PV Name               /dev/md2
VG Name               main
PV Size               7.90 GB / not usable 23.31 MB
Allocatable           yes (but full)
PE Size (KByte)       32768
Total PE              252
Free PE               0
Allocated PE          252
PV UUID               n2Qp6p-Afuc-CE2F-rtdi-7ypO-wnLw-rXtb0J
“/dev/sda3” is a new physical volume of “12.00 GB”
— NEW Physical volume —
PV Name               /dev/sda3
VG Name
PV Size               12.00 GB
Allocatable           NO
PE Size (KByte)       0
Total PE              0
Free PE               0
Allocated PE          0
PV UUID               nc37cI-D4hZ-sR8K-XB7r-Cxh4-N8vn-SecZIf
  • Now,  I add the physical volume to the Volume Group (this was helpful: I have a volume group “main” already. I have to add the physical partition to it.
# /usr/sbin/vgextend main /dev/sda3
Volume group “main” successfully extended
  • Now, add I have to extend the Logical Volume to use up all the new space in the Volume Group (see:
    • # /usr/sbin/lvresize -l +100%FREE main/root
Extending logical volume root to 19.34 GB
Logical volume root successfully resized
  • Ugh.  I still have to resize the EXT3 partition.
    • #/usr/sbin/ext2online -d -v /dev/main/root
  • Phew. It looks like I have a 20G root volume that works.
# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/main-root20G  6.3G   12G  35% /
/dev/md1               99M   16M   78M  18% /bootnone                  125M     0  125M   0% /dev/shm
Wow, LVM sure adds a lot of extra steps.  But, in the end, it’s pretty powerful.  It probably cost me time for my simple home network, but someday, I’m sure that I’ll run into LVM again.

How I had to fix PHP PEAR

Monday, March 10th, 2008

I’ve always found the code libraries of PHP PEAR to be quite useful.

But the PEAR website and individual package documentation is often baffling. I wish users could contribute comments and sample code easily, like the online documentation of PHP.

On to today’s rant. I just upgraded the Linux distribution that runs my home server to SME7, see Since it’s based on Red Hat Enterprise Linux, it comes with an old version of PHP Pear. Out of the box, it does not work. This is OK. On the frontpage of homepage the reason is clearly posted:

“[January 3, 2008] As promised, XML-RPC has been disabled at”

The news post tells you how to update older installs of PEAR to work with the new system. That would be fantastic, if the instructions worked.

But they don’t. At least for older than expected versions of PEAR.

Fortunately, I have notes from earlier this year on another server upgrade I did.  I had to search high and low to get my old version of Pear working. Earlier this year, I run these commands to upgrade and fix PEAR:

pear upgrade –force

(note, that’s all one command up there)

pear upgrade –force

pear upgrade PEAR

The difference is the Console_Getopt-1.2 line. It specifies the exact version of the Console_Getopt package to install. Shrug.

Today, I had an extra step:

On the second command, the PEAR-1.4.3.tar one, I go this error:
requires package `PEAR’ >= 1.3.3

I guessed that I needed to do a half-step upgrade first… i.e.
pear upgrade –force

Then do the original line:
pear upgrade –force

Then the final upgrade:
pear upgrade PEAR

I don’t know why PEAR had to disable the XML-RPC interface.  I don’t really care.  But I do find it annoying when the instructions on the front page of a site don’t work.

This problem will affect other people besides me. This will probably hit everyone else who is installing a new RHEL4 (or derivative) server. Long life distributions with non-functional PHP PEAR software will be kicking around for a few more years.

I’d post this on the PEAR Wiki. But there is none. Fortunately, this blog gets indexed by the search engines, so maybe it will prove useful to someone other than me.