Zentyal Forum, Linux Small Business Server

Zentyal Server => Installation and Upgrades => Topic started by: Kamilion on December 02, 2009, 10:57:38 pm

Title: Kamilion's Ebox Tweaks
Post by: Kamilion on December 02, 2009, 10:57:38 pm

This is gonna be a big thread, once I document all the hacks and tweaks I've done to my installation.

To start off, some links to the Installer Improvements threads:
Main Thread:
http://forum.ebox-platform.com/index.php?topic=2153
My Installer:
http://forum.ebox-platform.com/index.php?topic=1963.0

Some background on my situation:

I work for a subcontractor for NASA Ames Research Center (ARC).
ARC has good, decently configured firewalls with a default-deny policy. (Always Best)

However, this means that lots of stuff breaks. So, we're going to have to get creative to fix it.

Title: One OpenVPN Server to find them, and in the darkness, bind them
Post by: Kamilion on December 02, 2009, 10:57:56 pm

First Hack:
One Ebox to rule them, One OpenVPN Server to find them, and in the darkness, bind them...

I don't want to have to go through the hassle of configuring multiple OpenVPN servers, because eBox uses OpenVPN in 'routed' mode, not 'bridged' mode, so each OpenVPN server must have it's own subnet and doesn't share well.

Here's how to set up multiple port redirection to your single OpenVPN UDP Server port.
You must have the following modules enabled: ebox-network, ebox-firewall, ebox-openvpn.
Verify your OpenVPN server is operational on UDP port 1194. (Or change my instructions to suit.)
Go to UTM -> Firewall -> Redirects
Add a new redirect.

Settings:
Interface: Internet
Original Destination: eBox
Original destination port: Single Port, 443
Protocol: UDP
Source: Any
Destination IP: <Your External IP Here>
Port: Other, 1194

Click Add, then Save Changes.

Change your OpenVPN's client configuration from
remote <hostname> 1194
to
remote <hostname> 443

Test your new setup by connecting from another external network.

This should not impact an HTTPS server running on the same port, as HTTPS is TCP based, and OpenVPN is UDP based.
Make sure if you're redirecting port 443 for HTTPS that you use "TCP" as the protocol and not the default "TCP/UDP" as this will pass BOTH protocols.

Title: Network Booting and You
Post by: Kamilion on December 02, 2009, 11:26:16 pm

Second Hack:
Network Booting and You

eBox has support for serving a bootfile over TFTP.

Only it's broken. Oops.

Here's my quick fix:
sudo nano /etc/inetd.conf

Code: [Select]

tftp           dgram   udp     wait    root  /usr/sbin/in.tftpd /usr/sbin/in.tftpd -s /var/lib/tftpboot

That /var/lib/tftpboot is where tftp will serve files from.
eBox expects it to be serving a file such as:
/var/lib/ebox/conf/dhcp/eth0/firmware

Code: [Select]

tftp           dgram   udp     wait    root  /usr/sbin/in.tftpd /usr/sbin/in.tftpd -s /var/lib/ebox/conf/dhcp/eth0

Now when you 'upload' a new boot file to eBox's dashboard,
/var/lib/ebox/conf/dhcp/ethX/firmware
gets replaced with whatever you've uploaded.

But eBox won't set the dhcp-option 'filename' to serve it.

sudo nano /usr/share/ebox/stubs/dhcp/subnet.mas

Look for

Code: [Select]

% if(defined($info{'nextServer'})) {
                next-server <% $info{'nextServer'} %>;
% }
% if(defined($info{'filename'})) {
                filename "<% $info{'filename'} %>";
% }

And change it to

Code: [Select]

% if(defined($info{'nextServer'})) {
                next-server <% $info{'nextServer'} %>;
                # Filename entry added by Kamilion (dec 01 2009)
                filename firmware;
% }
% if(defined($info{'filename'})) {
                filename "<% $info{'filename'} %>";
% }

Now we need something to boot.

Go pick up the latest gPXE from here:
http://www.rom-o-matic.net/gpxe/gpxe-git/gpxe.git/contrib/rom-o-matic/build.php

Click Customize.

Change the following Settings:

[X] DOWNLOAD_PROTO_HTTPS
[X] DOWNLOAD_PROTO_FTP

[X] TIME_CMD
[X] DIGEST_CMD

And paste in the following Embedded Script: (Good base, but edit if you wish)

Code: [Select]

#!gpxe
echo "Greetings! Hit Ctrl-C to bail out."
sleep 5
echo "Going to DHCP on primary network adapter"
ifopen net0
dhcp net0
echo "Going to try http://netboot/default.gpxe"
chain http://netboot/default.gpxe
echo "Didn't work, we're still here. Falling back to http://boot/default.gpxe"
chain http://boot/default.gpxe
echo "Didn't work, we're still here. Falling back to BKO"
set 209:string pxelinux.cfg/default
set 210:string http://boot.kernel.org/bko/
echo "Here we go, off to boot.kernel.org!"
chain http://boot.kernel.org/bko/pxelinux.0
echo "Didn't work, we're still here. No Internet connection? Falling back to next BIOS Boot device"

You should get a single .pxe file back after clicking Get Image.

Go to DHCP -> Interface -> Advanced Options -> Thin Client.
Settings:
Next server: eBox
File Name [browse] <Choose gpxe-x.x.x+-gpxe.pxe>
File path in next server: <blank>

Click "Change" to complete the settings, then Save Changes.

Place this file in the root of your HTTP server, named default.gpxe, and create a DNS alias to that machine named 'netboot'.

Code: [Select]

#!gpxe
imgfree
chain http://netboot/boot/menu.gpxe

Here's an example you can use to load Parted Magic:

Code: [Select]

#!gpxe
imgfree
kernel -n img http://bigblock/boot/pmagic/4.5/bzImage load_ramdisk=1 prompt_ramdisk=0 keymap=us loglevel=0 rw sleep=4
initrd http://bigblock/boot/pmagic/4.5/initramfs
boot img

Here's an example you can use to boot from iSCSI.

Code: [Select]

#!gpxe
imgfree
#dhcp net0
set keep-san 1
sanboot iscsi:10.10.10.250::::iqn.bigblock:storage.iscsikarmic-one
chain http://10.10.10.250/boot/iscsi.gpxe

More examples here: http://files.sllabs.com/boot/ (http://files.sllabs.com/boot/)

Title: OpenVPN and DNS, a pushy combination
Post by: Kamilion on December 02, 2009, 11:30:11 pm

Third hack:
OpenVPN and DNS, a pushy combination...

eBox doesn't tell OpenVPN to push certain DHCP Options.

So we're going to have to edit the mason templates manually to do so.

sudo nano /usr/share/ebox/stubs/openvpn/openvpn.conf.mas

Scroll all the way down.

Before:

Code: [Select]

# Silence repeating messages.  At most 20
# sequential messages of the same message
# category will be output to the log.
;mute 20

<& advertisedNets, nets => \@advertisedNets &>

After:

Code: [Select]

# Silence repeating messages.  At most 20
# sequential messages of the same message
# category will be output to the log.
;mute 20

# Push options added by Kamilion (nov 03 2009)
push "dhcp-option DOMAIN it.mydomain.com"
push "dhcp-option DNS 10.10.10.254"
push "dhcp-option WINS 10.10.10.254"

<& advertisedNets, nets => \@advertisedNets &>

Now you can resolve internal hostnames from external OpenVPN clients!

Title: Re: Kamilion's Ebox Tweaks
Post by: J. A. Calvo on December 03, 2009, 01:21:31 am

Thank you again for your contributions!

Title: Re: Kamilion's Ebox Tweaks
Post by: Kamilion on December 03, 2009, 01:23:44 am

Quote from: J. A. Calvo on December 03, 2009, 01:21:31 am

Thank you again for your contributions!

No problem. More on the way. Once I hit 5-10, this may be useful enough to sticky.

Google (http://www.google.com)

Title: Re: Kamilion's Ebox Tweaks
Post by: martinb on December 05, 2009, 02:23:14 am

Man oh man! The OpenVPN hack is just what I needed! Many thanks!  ;)

Title: Re: Kamilion's Ebox Tweaks
Post by: c4rdinal on December 05, 2009, 04:12:18 pm

Kamilion,

These are very useful stuff. Many thanks and keep it coming!

Rgds,

Title: Re: Kamilion's Ebox Tweaks
Post by: sixstone on December 21, 2009, 10:11:49 am

Thanks very much for your contributions o:)

I especially like the one for thin clients :)

Cheers,

Title: Re: Kamilion's Ebox Tweaks
Post by: cl0s on December 23, 2009, 08:36:58 pm

yes... the network boot is golden. Thanks!

Title: Re: Kamilion's Ebox Tweaks
Post by: Kamilion on February 23, 2010, 12:08:36 am

Hope these've been useful for 1.3 users.

Busy updating everything for 1.4. Expect new content soon.

Title: Backing up components and Restoring individual components
Post by: Kamilion on February 23, 2010, 09:44:46 pm

First one in a while!

In upgrading to version 1.4, you may run into some issues with restoring old configurations.
The best way to avoid this is to do a clean install and only restore the module configurations you need.
In my case, the only thing I absolutely needed to save was openvpn.

Back up all Enabled Modules from the shell:

Code: [Select]

$ sudo /usr/share/ebox/ebox-make-backup --config-backup --description "OpenVPN Backup"
This will babble on about a bunch of redefined perl subroutines and then spit back something like:

Code: [Select]

Backup stored into file /var/lib/ebox/conf//backups/195129.tarat the end. At this point, the backup will also show up in the web interface.

You can get information on a backup tar like this:

Code: [Select]

$ sudo /usr/share/ebox/ebox-restore-backup --info /var/lib/ebox/conf//backups/195129.tar
      OpenVPN Backup
      Date: 2010-02-23 12:32:44
      Backup type: configuration backup
      Modules in backup: sysinfo network firewall apache ca dhcp dns events global logs ntp objects openvpn samba services squid usercorner users

These are the module names you need to give ebox-restore-backup.
You must import configurations for dependencies yourself, as in the next example, where I have to restore the CA configuration before OpenVPN.

Restore CA & OpenVPN:

Code: [Select]

$ sudo /usr/share/ebox/ebox-restore-backup --module ca /home/eboxadmin/eboxbackup.tar
$ sudo /usr/share/ebox/ebox-restore-backup --module openvpn /home/eboxadmin/eboxbackup.tar

Once this is complete, you can connect to the web interface, where you will have pending changes to save, and ebox should work out the kinks of most restores itself. (EG, when I restored OpenVPN above, the firewall rules were automatically updated the same as if I had created a brand new OpenVPN Configuration.)

If it requires something else, usually the error will be informative enough, I attempted to restore OpenVPN without the CA config first, and when I went to "Save Changes", it barfed because it had no certs to operate with, and aborted the save. So, be mindful of this.

Documentation on the tools themselves:
Restoring a backup:

Code: [Select]

root@cnc:/usr/share/ebox# ./ebox-restore-backup -help
  Usage:
  ./ebox-restore-backup  [OPTION]... [--module NAME]...   ARCHIVE_FILE
  ./ebox-restore-backup  --info ARCHIVE_FILE
  ./ebox-restore-backup  --help
  
  Options:
    --config-restore
    --data-restore
    --full-restore

    --force-dependencies

    --delete-backup

Making a backup:

Code: [Select]

root@cnc:/usr/share/ebox# ./ebox-make-backup -help
  Usage:
  ./ebox-make-backup  [OPTION]...
  ./ebox-make-backup  --help

  Options:
    --config-backup (default backup mode)
    --full-backup
    --bug-report

    --description <description>
    --remote-backup <name>

Many Thanks to Sixstone for quickly answering my question!

Quote from: sixstone on February 23, 2010, 10:39:28 am

If you only want to back up the OpenVPN and CA modules. You must do a configuration backup and then in the new machine. Perform the following command:

Code: [Select]

$ sudo /usr/share/ebox/ebox-restore-backup --module openvpn <archive_file>
You have more information in our documentation. (http://doc.ebox-platform.com/en/backup.html#command-line-tools-for-configuration-backups)

Title: Setting up Firefox Desktop mode in a better way for eBox 1.4
Post by: Kamilion on February 24, 2010, 12:00:54 am

Setting up Firefox Desktop mode in a better way for eBox 1.4

Great for KVM switches!

The user you created during the ebox-installer (first reboot, not ubiquity CD installer) is the account that runs firefox. It's configured for automatic login with that account on boot.

It's started from ~/.xsession and the default looks like this:

Code: [Select]

#!/bin/bash
firefox https://localhost &
exec blackbox

I change my admin port; so I had to change mine to something like:

Code: [Select]

#!/bin/bash
firefox https://localhost:443/LOGIN &
xset s off
xset -dpms
xset s noblank
exec blackbox

The xset stuff disables XOrg's built in screen blanking before launching blackbox.

Set this to false to prevent firefox from whining about restoring sessions after using 'halt' or 'reboot' from the web interface: about:config (http://about:config)
browser.sessionstore.resume_from_crash

Put this Blackbox Menu here: /etc/X11/blackbox/blackbox-menu

Code: [Select]

[begin]
  [sep]
  [exec] (eBox Firefox) {firefox https://localhost:443/LOGIN}
  [exec] (eBox root xterm) {gksudo xterm}
  [exec] (eBox xterm) {xterm}
  [sep]
  [config] (Configure Blackbox)
  [restart] (Restart Blackbox)
  #[include] (|/path/to/bash/script.sh)
  [sep]
  [exit] (Exit and Logout)
  [sep]
[end]

Set your firefox homepage/startpage to "https://localhost:443/LOGIN".

Firefox should now *always* go to the eBox login screen correctly after a reboot, halt, logout, firefox crash, or firefox close/reopen.

Some good firefox Addons:
Full Fullscreen (Disable toolbars) (https://addons.mozilla.org/en-US/firefox/addon/1568)
Fullscreen Statusbar (https://addons.mozilla.org/en-US/firefox/addon/13506)
secureFox (Password Exit) (https://addons.mozilla.org/en-US/firefox/addon/14365)
Refresh2Page (Go to homepage on timeout) (https://addons.mozilla.org/en-US/firefox/addon/14364)
TerminalRun (Highlight text to run in terminal, with nice warnings!) (https://addons.mozilla.org/en-US/firefox/addon/9738)

I'll be adding more to this as I figure out better ways to set up firefox as a configuration kiosk.

Next hack: Setting up FreeNX or NeatX to allow for remote GUI configuration over SSH. I need to play with NeatX first; otherwise I'll fall back to FreeNX which I've already gotten working.

Title: Fun with FreeNX
Post by: Kamilion on March 08, 2010, 01:17:03 pm

Fun with FreeNX

Well, NeatX didn't want to play well with hardy, oh well!

Code: [Select]

sudo nano /etc/apt/sources.list
and append the two lines for the repository

Code: [Select]

deb http://ppa.launchpad.net/freenx-team/ppa/ubuntu hardy main
deb-src http://ppa.launchpad.net/freenx-team/ppa/ubuntu hardy main

Save it and then exit nano. ( Ctrl-X, Y, enter)

To add the public key of FreeNX PPA run:

Code: [Select]

sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 2a8e3034d018a4ce
If you get timeouts with the above command, you may have to add a HKP entry to your firewall config.

Core -> Services
Create a new service.
Service name: hkp
Service Description: hkp for apt-key
Don't check "Internal". Add it, and edit the configuration with the notepad icon.
Add new.
Protocol: TCP/UDP
Source port: any
Destination port: 11371
Click Add.

UTM -> Firewall -> Packet Filter -> Filtering rules for traffic coming out from eBox
Add new.
Accept, Destination Any, Service hkp, inverse match unchecked, description hkp.
Click Add.

Try the apt-key command again until it adds the key.
You may need to add an outgoing http rule the same way as well; that service is already defined thankfully.
Make sure to disable them after you're finished adding keys and updating.

Code: [Select]

sudo apt-get update
After you add the repository, then install the freenx-server package.

Code: [Select]

sudo apt-get install freenx-serverIt'll pull in a mess of deps.

Now use nxsetup to install necessary files and create the special user "nx"

Code: [Select]

sudo /usr/lib/nx/nxsetup --install
Badabing -- grab the nxclient from NoMachine (http://www.nomachine.com/download.php) and you should be able to remotely login and use firefox just like a local console, protected by ssh2!

Title: Re: Setting up Firefox Desktop mode in a better way for eBox 1.4
Post by: J. A. Calvo on March 12, 2010, 10:28:21 am

Quote from: Kamilion on February 24, 2010, 12:00:54 am

Setting up Firefox Desktop mode in a better way for eBox 1.4

The 1.4-1 installer (http://www.ebox-platform.com/download/latest) that has been just released includes all these suggestions by default. Thank you very much for your contribution!

Title: Re: Setting up Firefox Desktop mode in a better way for eBox 1.4
Post by: Kamilion on March 12, 2010, 08:28:53 pm

Quote from: J. A. Calvo on March 12, 2010, 10:28:21 am

Quote from: Kamilion on February 24, 2010, 12:00:54 am

Setting up Firefox Desktop mode in a better way for eBox 1.4

The 1.4-1 installer (http://www.ebox-platform.com/download/latest) that has been just released includes all these suggestions by default. Thank you very much for your contribution!

Make sure you document the firefox startup stuff's hardcoded port of 443; otherwise users are gonna get a nasty surprise when they change the port from the web-interface and come back to the desktop view and scratch their heads wondering why it's now "page not found".

If possible, you should set up some mason templates for ebox-firefox to change the menu/xsession when the port's changed.

Also -- when you get around to ebox-software on lucid, it should offer to add-apt-repository ppa:ebox/1.5 if it's not already in the sources list (no should be a valid answer here too!). If the basic 1.5 packages get upstreamed before lucid's release like 1.3.5 did for karmic, make sure ebox-software is one of those upstreamed basic packages with this feature, so it's truly trivial to tell someone "install lucid-server then apt-get install ebox-software && enjoy_ebox" and have them result with an up-to-date ebox every time without jumping through the ubuntu SRU hoops.

If you're intending on getting the 1.4-era packages upstream before LTS hits, now's the time to get ebox-software working like this, so no matter what, ebox is easily installable right from lucid.

Title: Fun with SSL
Post by: Kamilion on June 17, 2010, 01:54:05 am

So, I got a SSL wildcart certificate for my primary domain not too long ago.

Getting ebox's certificates replaced wasn't too hard.

After chatting with bencer on IRC; I was told that if you *do not enable* "Services Certificates" that you should just be able to replace the .pem files in various locations with the proper keys without eBox replacing them on you with CA-generated certificates.

Messing around for a few hours, I got it all working, and here's how I did it.

OpenSSL isn't picky about what it finds in certificate files -- it's only looking for what it's interested in.
So, now knowing this, one can keep both the certificate and private key in a single .pem file.

What worked for me:

Code: [Select]

openssl x509 -in startssl.cert -text > header.pem && cat header.pem startssl.key > combined.pem
Alternatively, appending:

Code: [Select]

openssl x509 -in startssl.cert -text > combined.pem && cat startssl.key >> combined.pem


This will generate a .PEM file with a plaintext header (which is ignored) followed by the Certificate file, followed by the Private key file.

You can now use this combined.pem file to replace any of the eBox service certificates.

These files are stored in the following places: (owner.group, perms)

SMTP (postfix): /etc/postfix/sasl/postfix.pem (root.root, 0400)
IMAP (dovecot): /etc/dovecot/ssl/dovecot.pem (root.root, 0400)
POP3 (dovecot): /etc/dovecot/ssl/dovecot.pem (root.root, 0400)
XMPP (jabberd2): /etc/jabberd2/ebox.pem (jabber.jabber, 0644)
User Corner (apache2): /var/lib/ebox-usercorner/ssl/ssl.pem (ebox-usercorner.ebox-usercorner, 0400)
eBox Frontend (apache2): /var/lib/ebox/conf/ssl/ssl.pem (ebox.ebox, 0600)

Simply replacing these files and making sure the permissions matched the originals worked for me.

Of course, your milage may vary.

No mason templates were harmed in the making of this post.

Title: Getting rid of that darn Mason Error
Post by: Kamilion on August 06, 2010, 09:49:52 pm

HAVE YOU SEEN ME?

Use of uninitialized value in concatenation (.) or string at /usr/share/perl5/HTML/Mason/Component/Subcomponent.pm line 34.

MISSING CHILD; CALL 1-800-FOR-DEBIAN

How to bury this error in 1.4 and 1.5...

Code: [Select]

wget http://ftp.us.debian.org/debian/pool/main/libl/liblog-any-perl/liblog-any-perl_0.11-1_all.deb
dpkg -i liblog-any-perl_0.11-1_all.deb
wget http://ftp.us.debian.org/debian/pool/main/libh/libhtml-mason-perl/libhtml-mason-perl_1.44-1_all.deb
dpkg -i libhtml-mason-perl_1.44-1_all.deb

Looks like this is the debian bug report that triggered this fix in march 2010:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=436507 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=436507)

Someone should try to get 1.44 synced from debian with a SRU request, ubuntu's 1.42 still seems to show errors.

Problems? Revert your package to the ubuntu version.

Code: [Select]

(hardy) wget http://mirrors.kernel.org/ubuntu/pool/universe/libh/libhtml-mason-perl/libhtml-mason-perl_1.36-2_all.deb
(lucid) wget http://mirrors.kernel.org/ubuntu/pool/universe/libh/libhtml-mason-perl/libhtml-mason-perl_1.42-1_all.deb


Title: Decapitation with NoMachine 3.4
Post by: Kamilion on September 11, 2010, 12:54:09 am

Fun with Headless Zentyal!

Code: [Select]

apt-get install python-software-properties
add-apt-repository ppa:freenx-team
apt-get update
apt-get install freenx-server

Then set up your nxclient like this:
(http://files.sllabs.com/files/nxclient.png)

Title: Re: Getting rid of that darn Mason Error
Post by: J. A. Calvo on June 08, 2011, 01:44:57 pm

Quote from: Kamilion on August 06, 2010, 09:49:52 pm

HAVE YOU SEEN ME?

Use of uninitialized value in concatenation (.) or string at /usr/share/perl5/HTML/Mason/Component/Subcomponent.pm line 34.

MISSING CHILD; CALL 1-800-FOR-DEBIAN

How to bury this error in 1.4 and 1.5...

Hi Kamilion,

First of all, thanks for your feedback and sorry for the late reply!

I'm afraid that those versions that you refer fix a bug but does not remove all the Subcomponent.pm warning.

The Zentyal team already reported this in the mason list and the patch was never accepted:

http://www.mail-archive.com/mason-users@lists.sourceforge.net/msg02246.html

Now, we have backported libhtml-mason-perl from maverick to lucid and applied the patch by ourselves, and it is available in the official zentyal/2.1 ppa. So Zentyal 2.2 will no longer have this annoying warnings!

For anyone wanting to try these packages in Zentyal 2.0:

Code: [Select]

wget http://launchpad.net/~zentyal/+archive/2.1/+files/liblog-any-perl_0.11-1%2Bzentyal1_all.deb
wget http://launchpad.net/~zentyal/+archive/2.1/+files/libhtml-mason-perl_1.44-1%2Bzentyal1_all.deb
sudo dpkg -i liblog-any-perl_0.11-1+zentyal1_all.deb
sudo dpkg -i libhtml-mason-perl_1.44-1+zentyal1_all.deb

For those with a Zentyal 2.1 installed you only need to sudo apt-get update && sudo apt-get install libhtml-mason-perl

Title: Re: Getting rid of that darn Mason Error
Post by: innocenti_jr on June 08, 2011, 03:22:35 pm

Quote from: J. A. Calvo on June 08, 2011, 01:44:57 pm

For those with a Zentyal 2.1 installed you only need to sudo apt-get update && sudo apt-get install libhtml-mason-perl

Thanks for addressing this.
I just installed it and if something terrible happens, I'll post again. ;)

Cheers - Oliver