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
tar -xvvf 4Suite-XML-1.0.2.tar.bz2
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 @@
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"
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″?>
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:
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.
> Naturally someone here is going to say, upgrade to the last version it’ll fix these errors,
I’d never say that, upgrading most things is painful 🙂
I just wanted to suggest that instead of using ‘wget’ through to ‘setup.py install’, perhaps you could set up a Python virtualenv and then do ‘pip install 4Suite-XML’ (I assume that’ll work given the URL you downloaded from) into that virtualenv so that you can isolate your locally-installed packages in a directory of your own instead of them ending up in /usr.
Considering 4Suite-XML is over 10 years old, I don’t see why it’s not some package to quickly get. It’s already in a VM, so I really don’t care where it installs the files, I guess I’m too old for ‘virtual directories’ of pollution in VM’s to wave wands into containers to really care….. More so how to even go thru the python shuffle of adding stuff, and how it’s added zero progress from the days of having to compile crap for perl..