Upgrading Debian 8 to version 9

More so my own use, but this article on linuxconfig.org was a LOT of help.

Basically and with no explanation the steps are :

apt-get update
apt-get upgrade
apt-get dist-upgrade

dpkg -C

apt-mark showhold

cp /etc/apt/sources.list /etc/apt/sources.jessie

sed -i ‘s/jessie/stretch/g’ /etc/apt/sources.list

apt-get update

apt list –upgradable

apt-get upgrade
apt-get dist-upgrade

aptitude search ‘~o’

And that’s it!

I also took the BBR congestion update tip from tipsforchina.com

wget –no-check-certificate https://github.com/teddysun/across/raw/master/bbr.sh

And adding the following to /etc/sysctl.conf after the “net.ipv4.tcp_congestion_control = bbr” line.

fs.file-max = 51200
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.core.netdev_max_backlog = 250000
net.core.somaxconn = 4096
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 1200
net.ipv4.ip_local_port_range = 10000 65000
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_max_tw_buckets = 5000
net.ipv4.tcp_fastopen = 3
net.ipv4.tcp_mem = 25600 51200 102400
net.ipv4.tcp_rmem = 4096 87380 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864
net.ipv4.tcp_mtu_probing = 1

Manually adding ncurses & VDE support to the Linux Qemu build

For some reason I had issues for this to automatically pick up building Qemu 2.8.0 on Ubuntu 16.10 (Which is really Debian)…

Anyways, be sure to have the needed dev components installed.  If you have a FRESH system, natrually you’ll need a lot more.

apt-get install libvdeplug-dev
apt-get install libvde-dev
apt-get install ncurses-dev

editing the file config-host.mak, I found I needed to add the following to turn on ncurses & VDE:

CONFIG_CURSES=y
CONFIG_VDE=y

And lastly add in the following libs to the libs_softmmu, to ensure it’ll link

-lncurses -lvdeplug

And now I’m good!

From my notes on flags needed to run Qemu the old fashioned way:

-net none -device pcnet,mac=00:0a:21:df:df:01,netdev=qemu-lan -netdev vde,id=qemu-lan,sock=/tmp/local/

This will join it to the VDE listening in /tmp/local

Obviously I have something more interesting and more evil going on….

Firefly-Host-6.0-CloudSDK fun in “modern” times

Getting started

Ugh. nothing like ancient crypto, major security vulnerabilities, and ancient crap.  So first I’m going to use Juniper’s SDK (get it while you can, if you care).  Note that the product is long since EOL’d, and all support is GONE.  I’m using Debian 7 to perform this query, although I probably should be using something like 4 or 5.  Anyways first off is that the python examples require “Ft.Xml.Domlette” which doesn’t seem to have a 4Suite-XML package.  SO let’s build it the old fashioned way:

 apt-get install build-essential python-dev
wget http://pypi.python.org/packages/source/4/4Suite-XML/4Suite-XML-1.0.2.tar.bz2
tar -xvvf 4Suite-XML-1.0.2.tar.bz2
cd 4Suite-XML-1.0.2
./setup.py install

Well (for now) and in my case I could reconfigure tomcat to be slightly more secure. Otherwise running the examples gives this fun filled error:

ssl.SSLError: [Errno 1] _ssl.c:504: error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small

Naturally as time goes on this will not work anymore, and I’ll need a stale machine to query this stale service. Using ssl shopper’s Tomcat guide, I made changes to the server.xml file on the vGW SD VM. (Don’t forget to enable SSH in the settings WebUI, and then login as admin/<whatever password you gave> then do a ‘sudo bash’ to run as root, screw being nice!


# diff -ruN server.xml-old server.xml
--- server.xml-old 2017-01-14 18:20:07.000000000 +0800
+++ server.xml 2017-01-14 19:31:36.000000000 +0800
@@ -98,7 +98,7 @@
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" URIEncoding="UTF-8"
- ciphers="TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA"
+ ciphers="TLS_RSA_WITH_AES_128_CBC_SHA, ECDH-RSA-AES128-SHA"
keystoreFile="/var/lib/altor/cert/public_keystore" keystorePass="altoraltor"/&gt;

Naturally don’t forget to restart Tomcat, which does take forever:

bash-3.2# /etc/init.d/tomcat restart
Stopping tomcat: [ OK ]
Starting tomcat: [ OK ]

And now I’m FINALLY able to run  one of the sample scripts

# ./policyToXML.py –grp 1
<?xml version=”1.0″ encoding=”UTF-8″?>
<policy xmlns=”urn:altor:center:policy”>
<revision>340</revision>
<name>Global Policy</name>
<id>1</id>
<rev>1</rev>
<type>G</type>
<groupId>-1</groupId>
<machineId>-1</machineId>
<Inbound>

And you get the idea.  Certainly on the one hand it’s nice to get some data out of the vGW without using screen captures or anything else equally useless, and it sure beats trying to read stuff like this:

vGW VM effective policy for a VM

What on earth was Altor/Juniper thinking?  Who thought making the screen damned near impossible to read was a “good thing”™

I just wish I’d known about the SDK download on the now defunct firefly page a few years ago as it’d have saved me a LOT of pain, but as they say, not time like the present.

Naturally someone here is going to say, upgrade to the last version it’ll fix these errors, and sure it may, but are you going to bet a production environment that is already running obsolete software on changing versions?  Or migrate to a new platform? Sure, the first step I’d want of course is a machine formatted rule export of the existing rules.  And here we are.