JunOS SPACE installation notes

Installing JunOS SPACE can be a slog through documentation. These are my notes to help with the needed steps.

Edit: vSphere 6.5 can have issues installing the OVA file provided by Juniper. Until Juniper provides OVF files, you can install ovftools and convert the OVA using those.

ovftool -st=OVA -tt=OVF space-17.1R1.7.ova space-17.1R1.7.ovf

Source (.ova) and destination (.ovf) paths to be adjusted by you as needed.

-tt – Target Type (Explicitly express that the target is OVF, OVA, VMX, VMX, vSphere, vCloud, ISO, FLP, or vApprun)

-st – Source Type (Explicitly expresses that the source is OVF, OVA, VMX

Assuming SPACE is going to be installed on VMWare, as version 16.1 or better, this is the recommended sizing:

32GB RAM (OVA installs as 8GB, increase it)
4 vCPU
~ 500GB storage space total

The OVA installs as about 250G storage space. 100G of that is /var. You’ll want to add to that. Depending on the size of the environment being managed and whether this node will also handle integrated logs, anywhere from 250GB to 1TB of additional space is appropriate. It’s possible to add 250GB to start with and then add additional space if required.

SPACE can be deployed as a cluster, all in the same subnet, as well as in a DR scenario across L3 boundaries. Most of my customers run a single instance, as their environment is not large enough to warrant cluster deployment and they can rely on VMWare for DR purposes.

SPACE requires two IP addresses – one for the physical node and one for the VIP, used for HTTPS GUI access. Any additional nodes would need one additional address in the same subnet.

SPACE can use a second interface to communicate with devices if desired. This can be handy if the device management interface and the GUI access need to be in separate subnets.

SPACE does not offer a supported way of firewalling itself. You’ll want to firewall it in your environment, at a minimum restricting access to internal subnets, better yet restricting access to trusted subnets. This is a list of the services used, subject to revision should I miss a few. Juniper have a KB article on this which might be more accurate.

– HTTPS inbound for GUI access. Optional Ping inbound.
– If you are using eth0 for device management (no dedicated device management interface), and you don’t have a dedicated monitoring node: SNMP Trap inbound

Physical IP:
– ssh inbound for admin console access. Optional Ping inbound.
– DNS, NTP and SMTP outbound to your DNS/NTP/SMTP servers. Optional Ping outbound.
– HTTPS outbound to “*.juniper.net”, or if deploying as a customer instance connecting back to a Juniper partner, *.juniper.net and the partner SPACE proxy. When in doubt, this can be HTTPS outbound “to the Internet.” Optional Ping outbound.
– SNMP inbound if you are using an SNMP monitoring solution to monitor JunOS SPACE itself
– If you have a SPACE cluster with several nodes, they’ll communicate on that subnet using multicast. If multicast does not function in your environment, you can switch to unicast. I’m not sure what the implications of doing so are and prefer to run the default multicast configuration.

Physical IP or Device Management IP, if it was configured:
– ssh, ping and snmp outbound to device subnets
– ssh on port TCP-7804 inbound from device subnets
– snmp-trap inbound from device subnets, if the option to configure SNMP traps upon device discovery is set

If you have a dedicated device monitoring node, snmp-trap will be sent to it. If some of your devices will reach SPACE through NAT, you’ll want to read Juniper’s guidance on it.

These are the parameters you should have before you install SPACE:

  • DNS server address
  • NTP server address
  • Time Zone
  • VIP IP
  • Physical IP
  • Gateway IP
  • If SPACE will be behind a NAT device for device access, you’ll need to specify that during setup and have the NAT addresses handy
  • Node Name – for display in GUI, not the FQDN
  • admin password
  • maintenance password
  • super password
  • Desired FQDN – for DNS entry you will create
  • Cert for that FQDN – to avoid security warnings when connecting to GUI. This can absolutely be an internal trusted CA
  • Desired user authentication method – your options are Local, RADIUS and TACACS+
  • Juniper.net user name and password – for download of schemas and setup of ASAP, the pro-active service app
  • Any apps you will install such as ASAP (aka Service Now), Security Director, Network Director
  • If using Security Director or Network Director, license authorization keys for those and JS-PLATFORM. You’ll “cut” the license once SPACE is installed. If only using ASAP (ne Service Now), you will receive a permanent license once you connect SPACE to juniper.net, free of charge as long as you have at least one device under active maintenance.
  • SMTP server (and any authentication you need) for SPACE to send email
  • Username and password (or ssh key) you will use to manage devices. A “service account” such as “spcadmin” is often a good idea. This account needs “admin” rights in JunOS.
  • SNMPv3 or SNMPv2 read-only for use by SPACE. Optional (but recommended), allows Network Director and OpenNMS to monitor devices.

Once the OVA is installed, has been increased to 32GB RAM and has had an additional disk allocated to it – do NOT increase the size of the disk the OVA creates for you, that won’t work – you are ready to power it up and go through initial configuration. It’s pretty straightforward and asks for many of the parameters you gathered above.

The default username for console access is admin / abc123

The default username for GUI access is super / juniper123

When SPACE is up and running, you’ll have an option to expand virtual drive space. Choose it and assign all the additional disk space your VM guest received to /var. Be careful with this, if you accidentally assign it to another partititon (such as /, /tmp or /var/log), you’ll need to wipe the VM and start over.

Save your admin, maintenance and super passwords in an encrypted, centralized, backed up password safe. You can recover if you lose the admin password, but it takes access to the VMWare host and some effort.
“admin” is used for ssh access, “maintenance” is used for upgrades of the JunOS SPACE platform itself, and “super” is used for GUI access.

Additional housekeeping while on console and waiting for jboss and thus the GUI to start:

  • Change admin password expiration. Default is 70 days; you’ll likely want a longer timeout or “never”.
  • Change ssh session timeout. Default is 5 minutes. You can edit /etc/ssh/sshd_config and set ClientAliveInterval to 600 and ClientAliveCountMax to 3 and you’ll have 30 minutes.
  • Install VMWare Tools. Your VMWare admins will thank you.

If you want to avoid HTTPS security warnings when connecting to JunOS SPACE, create a DNS entry for its VIP address with the FQDN you chose, then create a cert (again, trusted internal CA is fine) for that. You’ll load that in the GUI under Administration -> CA/CRL certificates. Load the cert and any needed intermediate CAs.

Once in the GUI, you’ll want to change some of the default settings. Go to Administration -> Applications, right-click “Network Management Platform” and choose “Modify Application Settings”.
– “Allow Device Communication” is critical.
– “Add SNMP configuration to device for fault monitoring” can be useful if you want to use OpenNMS, but isn’t critical.
– “Configure commit synchronize” creates issues with single EX devices, uncheck that.
– “Manually resolve fingerprint conflicts” is probably more hassle than its worth for all but the most security-conscious customers.
– “Auto Resync”, “Approval workflow” and “commit confirmed” are useful
-Under “User”, set the timeout. 30 or 60 minutes seems reasonable for most environments.
– Under “Password”, set the password expiry in months. I’ve seen customers set this to “120” because they believe in the revised NIST guidelines and prefer good passwords over frequent changes.
– Under “Security”, the “Disable weak algorithms” checkbox will help the device pass an audit.

And hit “Modify”, wait for JunOS SPACE to restart its web server, and log back in.

If you are not going to use OpenNMS, you may disable it under Administration -> Applications -> Network Management Platform -> Manage Services

Under Administration -> DMI Schemas, set SPACE up to be able to pull DMI Schemas.
Click on the “Update Schema” icon, click the “SVN Repository” radio button and the “Configure” button. The URL is https://xml.juniper.net/dmi/repository/trunk/, the username and password are a juniper.net login that belongs to the organization running this SPACE instance. “Auto Install Schema” is a good idea as it avoids additional work. “Test Connection”, then “Save”.

Under Administration -> SMTP Servers, set up your mail server.

Under Administration -> Authentication Servers, set up your RADIUS/TACACS+ auth. I recommend “Remote-Local Authentication” so that you can still get into the unit using “super” if the remote authentication fails.

Under Administration -> Database Backup and Restore, you can set a backup to an scp server. It’s likely you’ll be relying on VMWare snapshots, but if you don’t have that in place, this is highly recommended.

Under Administration -> Purging Policy, set a policy to purge disk space periodically. Not really needed unless you take regular local DB backups or have very large device configuration files, in which case it becomes critical.

Under Administration -> CA/CRL certificates, install your HTTPS certificate.

Under Administration -> Fabric, enable the Cassandra service using Actions -> Enable Cassandra. This improves MySQL performance by offloading device image files to the Cassandra service.

Install any applications you’d like to use. ASAP (ne Service Now) is quite useful, and Security Director is the obvious choice for SRX policy management.

When deploying Security Director, I recommend also deploying a second node as Log Collector.  Unless you already have the SIEM IBM QRadar or Juniper JSA collecting logs, in which case you can just point Security Director towards those.
Log Collector will require another 16GB, 2 IP addresses (one in the same subnet as the main SPACE node for cluster comms and one for syslog, can be in the same subnet but need not be), and either 500GB of disk space and an NFS share, or 1TB (or more) of disk space to hold logs locally.

If you do use ASAP (Service Now), here are a few settings that’ll help you out:

You’ll add an “Organization”. If you are going through a partner proxy with PAR service instead of direct to Juniper, work with the partner on that setup. They’ll point your instance to their proxy, load a certificate file for their proxy, and they may set an auto-submit policy for incidents.

Administration -> Global Settings -> Core File Upload Configuration, set this to “Secure FTP upload through Service Now”. Otherwise devices will try to FTP directly to juniper.net and that will likely fail.

Here are some good videos by Juniper on using ASAP:

Video #1: https://www.youtube.com/watch?v=EM2w86T96Ac
Video #2: https://www.youtube.com/watch?v=HiAKA2ItROg
Video #3: https://www.youtube.com/watch?v=gU-f1hxttCY
Video #4: https://www.youtube.com/watch?v=a9mUSmJXST4


Lastly, when adding devices to SPACE, consider assigning them a public tag such as “All Devices” and configuring Configuration Files backup to act on that tag on a schedule, say once a day.

You can create schedules to find new devices automatically, and you can of course use the base JunOS SPACE application to upgrade firmware and make bulk configuration changes.


JunOS SPACE upgrade to 16.1r2

These are my notes for upgrading JunOS SPACE from 15.2r2 to 16.1r1 or 16.1r2. They are meant to be consumed together with Juniper’s upgrade instructions. Since you are installing a fresh copy of JunOS SPACE as part of this upgrade, maybe now is also a good time to revisit some default settings.

  • 16.1 is the first release where the default partition sizes in the OVA are “sane”. The only partition you’ll need to add to is /var. It is 100GB large by default. An additional 250GB is fine for most installations; large installations with massive DBs might want as much as an additional 1TB.
  • You may not have enough space on the disk to take a backup using the 15.2r2 backup patch as long as OpenNMS remains enabled. In that case, disable it; then after reinstall and import, take additional steps to re-enable it. Disabling OpenNMS is done from Administration -> Applications -> Network Management Platform -> right-click and Manage Services
  • When taking the backup, I then opted not to backup PGSQL (that’s OpenNMS) and FMPM (since I happen not to have any FMPM nodes). This reduced the size to something manageable.
  • You may need the ServiceNow image file when taking the backup. If so, copy it to SPACE using command-line scp, then move it to /var/cache/jboss/jmp/Service-Now.VERSION (the backup process will tell you the exact location), and hit Enter to let the backup continue. For Service Now 16.1r1, the location is /var/cache/jboss/jmp/Service-Now.16.1R1.15
  • You will require an external scp server to copy the backup file to, or you can use a USB stick with FAT32 (no more than 32GB) if upgrading a JA2500 appliance.
  • Front USB is detected as /dev/sdb, use dmesg to make sure. Then mount:
    mkdir /tmp/pendrive
    mount -t vfat /dev/sdb1 /tmp/pendrive
    You can check with fdisk -l
  • To restore from USB, go through initial configuration.  When you come to restore choice (Remote, USB, Local), ssh to device and mount -t vfat /dev/sdb1 /tmp/pendrive, then use serial console to choose USB
  • If you don’t have an scp server, you can choose during backup; then copy the file over to the new server during restore and choose “Local”
  • You will need these things to configure your new SPACE instance:
    DNS server
    NTP server
    VIP IP
    Phys1 IP
    Phys2-N IP
    GW IP
    License File
    List of Apps
    admin password
    maintenance password
  • After restoration, adding space to /var etc, check the settings for Network Management Platform. “Allow device communication” may be off. Turn it on so devices will move to “Up” status.
  • For a secondary node, it doesn’t ask for NTP on initial setup. Set this and TZ manually. Once secondary node is up, you’ll need to add it from GUI as well.
  • Don’t forget chage admin and the ClientAliveInterval / ClientAliveCountMax in /etc/ssh/sshd_config
  • If you disabled OpenNMS before the backup, it won’t start after import. This is how you get it back in a default state.
    Disable OpenNMS from GUI
    service postgresql-9.4 status
    If it’s down: service postgresql-9.4 start
    Now to create the DB:
    service jmp-watchdog stop
    service jmp-opennms stop
    For the following, passwords are postgres and opennms respectively
    psql -U postgres -c ‘ALTER ROLE opennms SUPERUSER’
    psql -U opennms postgres -c ‘drop database opennms;’
    psql -U opennms postgres -c “create database opennms encoding ‘unicode'”
    psql -U postgres -c ‘ALTER ROLE opennms NOSUPERUSER’
    /opt/opennms/bin/install -dis
    service jmp-watchdog start
    Then enable OpenNMS from GUI


JunOS SPACE fails when upgrading applications

When upgrading JunOS SPACE, the applications installed on it need to be upgraded as well. I’ve seen jboss crash and restart when several applications are upgraded in a row. This happened after moving to SPACE 16.1r2 and then again when upgrading to 17.1r1.

JTAC advised that the issue is that Java runs out of “PermGen” memory. Assuming that SPACE is installed on a JA2500 or a VM with 32GB of memory, these changes should resolve the issue. They may have to be reapplied after each upgrade of the core SPACE software.

  • stop jboss and watchdog
    service jmp-watchdog stop
    service jmp-watchdog status (make sure it has stopped)
    service jboss stop
    service jboss status (make sure it has stopped)
  • edit /var/jboss/domain/configuration/host.xml.slave and change
    <option value=”-XX:MaxPermSize=512m”/>
    <option value=”-XX:MaxPermSize=1025m”/>
  • start watchdog
    service jmp-watchdog start
    service jmp-watchdog status

    The watchdog process will restart jboss so there is no need to restart jboss manually.


Installing VMWare Tools (Open VM Tools) on JunOS SPACE 16.1 or newer

These instructions are for JunOS SPACE 16.1 or newer. I also have instructions for JunOS SPACE 15.2 or older.

JunOS SPACE, Juniper’s management tool for JunOS devices (switches, routers, firewalls), officially supports Open VM Tools for management from ESXi. Unfortunately, Juniper’s instructions are to build Open VM Tools, and that won’t work without a dev environment, which is not present in JunOS SPACE.

SPACE 16.1 is built on CentOS 6, which in turn is a RHEL 6 clone. Open VM Tools exist in CentOS 6 repositories, so all we need to do is to enable those repositories and we can install binaries.


Navigate to /etc/yum.repos.d and create a new file named centos6.repo, with this content:

name=CentOS 6 Repository

name=CentOS 6 Extras Repository

Back on command line, add the EPEL repository:

yum install epel-release

Install Open VM Tools:

yum install open-vm-tools

Start them:

service vmtoolsd start


For good measure, you can now disable the centos 6 and epel repos again, by editing centos6.repo and epel.repo in /etc/yum.repos.d/ and setting this line for centos6, extras, and epel:


Verify those repos are disabled:

yum repolist


WSL “Bash on Windows” as a dev environment

I don’t aim to introduce WSL, or do more than link to installation steps.

I do want to take a quick note of tweaks that have been helpful to me in making WSL more useful as a development environment.

  • If you want to use ping: Find the “Bash on Ubuntu on Windows” shortcut, right-click, more, open file location, right-click, properties, advanced, “Run as administrator”. Presto, ping works. This might not be necessary in future builds.
  • Friendlier colors:
    • Edit .bashrc and add to the bottom:
    • LS_COLORS=$LS_COLORS:'di=1;44:' ; export LS_COLORS
    • Edit .vimrc and add:
    • :set background=dark
    • Optional, not entirely certain about this yet: Right-click the bash icon at the upper left of the bash window, choose Defaults, set “Screen Background” to “Black” (0,0,0) and “Screen Text” to “White” (255,255,255)
  • /mnt/* is not a build environment. If you try to compile something you downloaded in Windows from its /mnt/c or /mnt/* location, copy it over to ~/ or /var/tmp first. /mnt/* is not as “Linux-y” a file system as the Ubuntu environment is, and it might (likely: will) trip up your source builds.
  • Coding in perl 5: Works out of the box from Creators Update on. Until then, edit “/usr/lib/perl/5.18.2/Config.pm” and make sure that you have “dont_use_nlink => 1”, around line 94. It defaults to “dont_use_nlink => undef”.
  • Coding in perl 6: Requires a change to the dyncall library to build successfully for now, until dyncall has been updated. The MoarVM github has two alternate patches that will allow it to build, only one is required.
  • Coding in Swift: Similar issue to perl 6, with a patch available. Your best bet is to clear the executable stack flag in libFoundation.so for now, until Swift 3.1 has been released.
  • Coding with a host of other libraries that refuse to link because of execstack, including OpenSSL: Clearing the executable stack flag on the library will work if the library doesn’t require an executable stack. Upstream changes would be best, however, so things start working “out of the box”. Usually the root cause for a library setting the execstack flag is that assembly files are missing a short section to declare the stack not executable. See the Gentoo wiki entry on this. Here’s the code that would go into a .h file included in every .S file, with NO_EXEC_STACK_DIRECTIVE at the end of relevant .S files. NB, this needs to be .S not .s, as a preprocessor is required in order to parse the include file:
  • #if defined(__GNUC__) && defined(__ELF__) && (defined (_linux__) || defined(__FreeBSD__) || defined(__ANDROID__))
    #define NO_EXEC_STACK_DIRECTIVE .section .note.GNU-stack,"",%progbits
    #elsif defined(__SUNPRO_C) && defined(__linux__)
    #define NO_EXEC_STACK_DIRECTIVE .section ".note.GNU-stack"

    That code is portable using GNU as across architectures, and should work with SUNPro Tools aka Oracle Developer Studio.

    Please also see the WSL github discussion regarding execstack. This really can use attention and will have positive impact beyond WSL when resolved. Requesting an executable stack when it’s not needed is an exploit waiting to happen.

JunOS SPACE upgrade hangs at 0%

I attempted to upgrade a JunOS SPACE instance from 15.2R1 to 15.2R2. It would sit at “upgrade process has not started” and 0%. If I changed the URI to the base, I’d be back in the SPACE GUI as if nothing had happened and I had never entered maintenance mode.

This was caused by a failed upgrade months earlier which left a msg.<date> file behind in /var/jmp_upgrade/master/msg . Deleting that file allowed me to successfully upgrade the unit.

After a successful upgrade, the msg/ directory will be empty in both the master and slave directories.

In the process, I learned about a few more files that SPACE looks for. If these exist from a failed upgrade, they can keep a new upgrade from starting. Delete these if they exist:



You can find a clue as to why your upgrade is not proceeding in these two directories:



Look for log files named after the current and target SPACE version.

Also monitor this file for any issues with maintenance mode:



“Cyber Security” for home PCs

Concerns about online security are widespread. No-one wants their logins and finances compromised. How to act on those concerns can be confusing.

How security pros and general users go about securing their devices is quite different. Users often rely on software such as AntiVirus. Security pros likely also use AV, but it’s not their first line of defense.

I’ll share what I consider to be good practice, and what has kept my own machines free from malware for well over two decades now.

  1. Patch religiously, fanatically
  2. Use a password safe and unique passwords
  3. Don’t pirate anything
  4. Be a little paranoid about attachments and links in email
  5. And sure, for defense in depth, run some AV. Chances are it’ll never find anything, though.

If you are only going to do a little, then patch and start using  a password safe. That will give you the biggest bang for your effort.

Let me go into those in some more detail.

Patch religiously, fanatically

This is all about what we security geeks call “attack surface”. The fewer vulnerabilities your system has, the less likely it is to be compromised. The amount of machines that are compromised through known, long-discovered and long-patched vulnerabilities in, say, Adobe Flash, is truly staggering.

So patch religiously. Set everything you can to auto-update. That includes the OS itself, the browser, Java, Flash, Adobe Reader, and really any piece of software that can be updated.

A corollary to this is to reduce the amount of software you need to be on top of.

Not running any Java code? Uninstall Java.

Using a browser that contains its own version of Flash, such as Google Chrome or MS Edge or MS IE 11? Ditch the standalone Flash install.

The main vectors for compromise for a few years running have been Adobe Flash, Adobe Reader, and Oracle Java. Word and Excel get a (dis)honorable mention.

Use a password safe and unique passwords

Passwords are still with us, they’ll continue to be with us for a long time, and they are a terrible way to secure access to important stuff.

So, at the very least, make things easy on yourself and hard on attackers: Use a password safe. There are a number of options available, but if you don’t have very specific criteria, you can’t go far wrong with LastPass. It combines convenience with security.

Convenience is important: If using unique passwords becomes a chore, you likely won’t do it. LastPass will fill in passwords, log you in automatically, generate strong passwords for you and, if you want it to, even change passwords periodically for you.

For your “master password” for LastPass, one good idea is to choose a number of unrelated nouns. An example is “Correct Horse Battery Staple”. Just, for the love of security, do not use that actual example, because it’s a published example. Passwords only work if they are secret.

And then you can start assigning unique, strong passwords to all of your critical accounts. Eventually, all of your accounts. LastPass can help with that chore by running a check on your password database and telling you where you have duplicates and where you have weak passwords.

If you are going to run AntiVirus, there is a copy of LastPass bundled with Webroot, so that’s an option to cut down on the number of software packages you subscribe to.

Don’t pirate anything

What’s this, blogger Dad Mode? The thing about pirated content is that it often comes with something extra, that extra being malware. Once you invite malware into your system, all bets are off. The easiest way to avoid that vector of compromise is to just buy everything outright.

Adult video sites are also notorious for attempts at “drive-by” installs of malware, so browse with care.

Be a little paranoid about attachments and links in email

This is a tough one. Even security pros fall for so-called “spear phishing” attempts, emails with attachments that look legitimate and look like they come from a trusted source, but are actually carriers for malware.

That said, most of those kind of emails are pretty crude. If you’re being asked to “verify your account” or “enter your password here”, that won’t be a legitimate email.  Unless you know you just initiated a password reset yourself and you expect that email. And that’s where it gets a little tough to distinguish between the two. So, be cautious. Check the sender address. When in doubt, manually browse to the site in question, don’t click on the link in the email.

For attachments, if it’s not from a trusted source and you don’t expect it, delete it. No, UPS doesn’t send you word documents. 🙂

Run some AV software

This is really dead-last. AntiVirus software will not detect a lot of malware, and this is meant only to give you one last chance to stop something if all the above defenses fail. If you are not patching religiously and using strong passwords, start there, not here.

I do run AV, as a last-ditch defense if everything else fails, and in the past two decades, my AV hasn’t picked up anything but emails I didn’t act on. I could arguably run without AV and be fine. But then I’d always be wondering whether something slipped through my defenses, after all, so out of an abundance of caution, I pay a subscription for “Medicine”.

Traditional signature-based AntiVirus software can catch maybe 18% of what’s out there, on a good day. So that’s pretty useless. Happily, the industry is evolving.

The best option for a home user – and I say this because as far as I know, it’s the only option for a home user that has modern detection mechanisms – is Webroot, as of November 2016. It happens to come with a copy of Lastpass, reskinned as Webroot Password Manager, so that’s a big plus. Webroot does not do signature-based detection, instead it’s using behavior analysis.

There are other “Next Generation AV” products out there, but nothing else that fits the budget and needs of a home user as far as I am aware.

If you want to add a little bit more protection, then Malwarebytes Anti-Exploit Free is a good choice to protect browsers and Adobe Reader. To get it free, just download the trial and wait for the trial period to expire, then switch it to free mode.

And if you absolutely want more “medicine” and don’t mind paying for it, the full Malwarebytes package is a good choice. I’m running it, but honestly, I wouldn’t install it on my mom’s PC. That’s arguably overkill when patching, secure password use, Webroot, and Anti-Exploit Free are already in place.