Junos 10

Today I have been mostly installing Junos. Well actually I’ve wasted most of the day trying to get Junos 10.4 to work in Olive under VirtualBox. I understood that it required FreeBSD 7.1, so tried installing it under 7.1 and 7.4 to no avail.

In the end I cloned my Junos 9.0/FreeBSD 4.11 VM, allocated 512Mb instead of 256Mb and installed 10.4 as an upgrade, which also meant I didn’t have to bother removing checkpic.

I wasted a few rounds of installing due to using the export version, which doesn’t include SSH! Also part of the trick of getting it to work under VBox seemed to be to create a serial port as a named pipe – not sure why but that seemed to help get past the bootloader hanging, possibly as it had a TTY to allocate.

I also upgraded my 9.0 to 9.6 which has a bit of a more useful JWeb interface, and also requires 512Mb now.

All of this was to aide my development of a set of NASL scripts to do Junos security compliance auditing. It seems Tenable have worked around the UNIX-only limitation of Nessus’ ssh_cmd() function by putting in a special check for when uname -a fails – i.e. its either IOS or Junos (or unsupported). Of course in Junos shell mode, it will pass (as its FreeBSD) so you have to check that you’re in CLI mode to do the config checking.

Its only taken them four years of me asking for this, and I guess its come as a result of Nessus’s new IOS support for their own compliance plugin and local security checks for Junos patches etc.

Update: I’ve written 20 NASL plugins to do the Junos auditing now and I noticed I was hitting the SSH rate-limit setting in Junos, so my plugins were getting booted off. It was because for each plugin I was calling ssh_cmd() at least once and also a function that checks I could login with the correct level/privileges etc; so was making at least two SSH connection attempts per plugin, which soon hit the 10 connection attempts per minute limit that was configured.

So now I’ve moved all of my ssh_cmd() calls into one big include file which uses a single SSH connection to send 30 or so commands, and populates the knowledgebase with the results. The plugins then have that in their script_dependencies() and don’t use SSH at all, just a couple of calls to get_kb_item() which simplifies the code quite a lot and an entire scan can be done in 10secs!

Plex for Linux and Android

Today I’ve been playing with PMS (Plex Media Server) for Linux, and also Plex Mobile for Android. Both have been pretty disappointing!

The Linux server is closed-source and precompiled for vague platforms like 32-Bit Ubuntu 10.10, but happens to run with some work on 64-Bit, I got it working on 32-Bit 11.04 after some hacking.

It looks like a direct port of the Mac version though as there’s no init script and there are spaces and capital letters in filenames, which actually stops the server from starting (good QA there!)

Then it seems like too much hassle to point a Mac client to it, as you have to have the same NFS mountpoints or something odd, and you can’t manually select a server from the client, you have to rely on stupid ZeroConf/Avahi.

To my surprise though, I ran it in a VirtualBox VM and allocated 256Mb RAM to it and it worked fine – so why does PMS seem to bog down my 2Gb MacMini?

I thought I’d try the Android client. Well that’s the slowest app I’ve ever seen (and paid £3 for) and on Cyanogenmod it doesn’t even play video, only sound works – and no its not due to lack of Flash10!

The promised remote control functionality hasn’t been written yet, although you can see its a direct port of the iOS app as the remote icon is there, it just does nothing!

So once again it seems Plex is not serious about running client or server on non-Apple platforms.

Compiling CM7 on Fedora

I decided to have another go at compiling CM7, this time using Fedora 13 on real hardware rather than an virtualised Ubuntu 10.10, which also means adb/udev is already working from when I rooted the ZTE Blades.

I downloaded and installed the Oracle/Sun JDK 6u24 (which includes the JRE).

Setting up “alternatives” to point to the Oracle JDK instead of OpenJDK/GCJ doesn’t work 100% as at least javadoc, appletviewer and javah have to be manually symlinked:

ln -s /usr/java/jdk1.6.0_24/bin/javadoc /usr/bin/javadoc
ln -s /usr/java/jdk1.6.0_24/bin/appletviewer /usr/bin/appletviewer
ln -s /usr/java/jdk1.6.0_24/bin/javah /usr/bin/javah

None of the below tutorials explained why “alternatives” doesn’t work:

Just for good measure I added the following to ~/.bashrc

export JAVA_HOME="/usr/java/jdk1.6.0_24"

After that the compile worked, except it got stuck at some point with a javadoc problem, a quick “make update-api && mka” fixed that.

The cyanogen wiki instructions are incomplete regarding making an AVD using your ROM. Also CM7 now uses the 2.3.3 v10 API, so the last stage should really be:

cd ~/android-sdk-linux_x86/platforms/
cp -R android-10/ android-10-cyanogen/
cp ~/cyanogenmod/out/target/product/generic/*.img android-10-cyanogen/images/
 
cd ~/.android/avd/
cp -R Gingerbread.avd/ cyanogenmod.avd/
cp Gingerbread.ini cyanogenmod.ini

Edit ~/.android/avd/cyanogenmod.ini to read:

target=android-10
path=~/.android/avd/cyanogenmod.avd

Edit ~/.android/avd/cyanogenmod.avd/config.ini to read:

hw.lcd.density=240
skin.name=WVGA800
skin.path=platforms/android-10-cyanogen/skins/WVGA800
vm.heapSize=24
hw.ramSize=256
image.sysdir.1=platforms/android-10-cyanogen/images/

Then you end up with:

CM7

Compiling VirtualBox OSE

Building VirtualBox is getting harder and harder these days as Oracle add non-standard hacky little scripts to the codebase, just like their horrible database installation that requires you to install RPM’s to allow the installer to run, then you must remove them afterwards or your entire system will be un-upgradeable!

The build instructions here are hideously out-of-date and don’t really help much on a non-Debian system.

The first bug was a dependency on a specific version of Java, or more accurately a hardcoded location for the JRE. The fix for that was a symlink for OpenJDK, not installing the Sun JVM as they said. So as root:

cd /usr/lib/jvm/
ln -s java-1.6.0-openjdk.x86_64 java-6-openjdk

Another problem I had was that they silently started building the packages using makeself, which became a requirement, even if you used ./configure --disable-hardening, which is not supposed to build distributable packages. makeself is not packaged, so just untar it in /usr/local/bin/ as root.

Recently it seems they’ve added to the mix, compiling the UserManual.pdf using LaTeX and an obscure font. The fix for that appears to be to download and install the font, as root:

cd /usr/share/texmf/tex/latex/
mkdir bera
cd bera/
wget http://www.tug.org/texlive/devsrc/Master/texmf-dist/tex/latex/bera/beramono.sty
texhash

They’ve removed compiling the VBoxFixHDD utility as I suggested (as the code wasn’t in SVN, but the dependency was!) by commenting out line 53 of vbox/src/VBox/Devices/Storage/testcase/Makefile.kmk

#PROGRAMS += VBoxFixHdd

So OSE revision 32218 (newer than PUEL 3.2.8) now compiles on 64-Bit Fedora 13 again. There doesn’t appear to be anything hugely new, other than a redesigned GUI with a preview window.

VirtualBox 3.2.0

Whilst I’m waiting for my new hard disk to arrive for my Core-i5, I needed to use VirtualBox, so I decided to install it on my E5300 fileserver, which luckily has VT-x support, and of course is running a 64-Bit Ubuntu 9.10 install with 4Gb RAM.

It actually was easier than I expected, similar to the Fedora method you just add the repository to your /etc/apt/sources.list, import Oracle’s GPG key and run “sudo apt-get install virtualbox-3.2″ as described here; which even pulls in the dkms system to rebuild the kernel modules automatically.

Then I just added my username to the vboxusers group and copied over my ~/.VirtualBox/ directory from the Core-i5, editing the paths to the VDI’s to point to the backups I made.

I had to upgrade my BIOS as it seems the one I was using didn’t actually have an option to enable VT-x, although it was detected in the flags of /proc/cpuinfo