Mid server on raspberry pi

Jon Ulrich · ‎02-26-2017

The essential guide to getting a mid server on a raspberry pi

Recently I attempted to get a mid server running on my raspberry pi and could find no clear instructions. Here is what I did to get it working on a Pi 3 model B running respian jessie light, hopefully it can help you out in your efforts.

1. As the JRE the mid server comes with does not work on the arm archectature, you must install the ARM version of JRE
  1. sudo apt-get install openjdk-8-jre-headless
2. Create destination for your mid server files
  1. sudo mkdir /servicenow
  2. cd /servicenow
3. Figure out what mid server you need.
  1. from your instance, navigate to Mid Server > Downloads in the left nav
  2. right click 32 bit under linux, and copy URL / Link Address
4. Download mid server files into your servicenow directory
  1. sudo wget https://install.service-now.com/glide/distribution/builds/package/mid/2017/01/11/mid.istanbul-09-23-...
5. Unzip your files. From here we will be modifying the /servicenow/agent directory to change things to work on the pie. Once this is done, the /servicenow/agent directory will be used to copy to each mid server you need
  1. sudo unzip mid.[press tab to auto complete]
6. Figure out your exact processor architecture. Run the command and review the highlighted line
  - uname -a
    pi@urchpi01:/servicenow $ uname -a
    Linux urchpi01 4.4.34-v7+ #930 SMP Wed Nov 23 15:20:41 GMT 2016 armv7l GNU/Linux
  - NOTE! The last character in the above example is a lowercase letter L !!
7. Setup the wrapper files matching your pi's architecture
  - If your architecture is armv7l, setup symlink to existing wrapper:
  - - sudo ln -s -r /servicenow/agent/bin/wrapper-linux-arm-32 /servicenow/agent/bin/wrapper-linux-armv7l-32
  - If your architecture is armhf, download the attached armv6l.zip file, and place the files in the following locations:(Thanks to Lance D'Souza for noting this)
  - - /servicenow/agent/lib/libwrapper-linux-armhf-32.so
    - /servicenow/agent/bin/wrapper-linux-armhf-32
8. Edit wrapper override configuration to point to external JRE and change max memory
  1. 1. sudo nano /servicenow/agent/conf/wrapper-override.conf
    2. Under External JRE uncomment the line for wrapper.java.command and update to the following
      - wrapper.java.command=/usr/lib/jvm/java-1.8.0-openjdk-armhf/jre/bin/java
    3. Under System resources uncomment wrapper.java.maxmemory, and set to a value that makes since for your Pi. My Pi has 1gb of memory, and I plan on running 2 mid servers so I chose 256 mb. I have been running it solid for a few days now without issue.
    4. [Ctrl + x] exits, select [Y] save, enter for current file location
9. Edit the wrapper file to correct the processor architecture (Thanks to Robert Beeman for noting this)
  1. sudo nano /servicenow/agent/conf/wrapper-jvm.conf
  2. change set.SNC_JVM_ARCH=x86-32 to set.SNC_JVM_ARCH=arm
10. Now copy the folder for your mid server and copy the agent into it
  1. Setup the directory and move mid into it
    1. sudo mkdir [your_mid_server]
    2. sudo cp -r /servicenow/agent/ /servicenow/[your_mid_server]/agent/
    3. cd [your_mid_server]/agent/
  2. Config your mid server
    1. sudo nano ./config.xml
    2. Edit file as normal
    3. [Ctrl + x] exits, select [Y] save, enter for current file location
  3. Start it up / test it out
    1. sudo ./start.sh
11. You can use cron to automatically start your mid server when the pi boots
  1. sudo crontab -e
  2. Add these lines to the bottom of the cron file. First I delete the old logs so the current log remains agent0.log, then I start the mid. I cd first because from what I can tell some of the paths in the start script are relative and break if you don't start form the correct directory.
    1. @reboot sleep 10 && rm -r /servicenow/[your_mid_server]/agent/logs/*
    2. @reboot sleep 11 && cd /servicenow/[your_mid_server]/agent && ./start.sh
    3. [Ctrl + x] exits, select [Y] save, enter for current file location

Repeat step 10 and 11 for multiple mid servers

Troubleshooting

1. "Unable to locate any of the following binaries:"
  - This message occurs when there is not a wrapper file that matches your processor architecture.
  - Review the binaries that are supposedly missing and create symlinks to those specific names similar to step 7 above.
  - Remember in my examples, the last highlighted character is a lowercase L NOT a number 1.
2. Review logs/wrapper.log
  1. If you see error messages for missing files, create symlinks from the existing ...arm... file to the missing file similar to step 7
    - I had these symlinks in a earler version of this document, but thought them unnecessary. If you are having problems, try adding these symlinks back in. Be sure to add them to each mid instance's directory:
      - sudo ln -s -r /servicenow/agent/lib/libwrapper-linux-armhf-32.so /servicenow/agent/lib/libwrapper-linux-null-32.so
      - sudo ln -s -r /servicenow/agent/bin/wrapper-linux-arm-32 /servicenow/agent/bin/wrapper-linux-armv7l-
  2. If you see error messages for mismatch versions:
    1. Review available jre versions
      1. sudo apt-cache search jre
    2. Review installed jre versions
      1. ls -l /usr/lib/jvm/
    3. Go back to step 8, and try the different JRE versions.
3. Wifi can be difficult to get up and running for those of us not familiar on linux command line. Here is the guide that helped me get wifi running: Setting WiFi up via the command line - Raspberry Pi Documentation. You should only need to configure the /etc/wpa_supplicant/wpa_supplicant.conf file.

sabell2012 · ‎03-03-2017

This is awesome! Thanks for sharing! 🙂

Robert Beeman · ‎05-22-2017

Hello jonathan.ulrich,

Thank you for this excellent post! I'm trying to use it to set up my own Raspberry Pi MID Server to experiment with.

It appears that I'm failing to start the MID Server though. I'm getting the warning below, and there is nothing in my /agent/logs folder to aid in troubleshooting. It doesn't appear to have connected to my instance either. Have you seen this before? Are there any tips you have for me to figure out what's going wrong? Thanks in advance!

Jon Ulrich · ‎05-23-2017

is there anything in the /servicenow/RPiMidServer/agent/logs folder?

Robert Beeman · ‎05-23-2017

No, it is empty, which is contributing to my confusion.

Robert Beeman · ‎05-24-2017

I think I might have figured it out. I had to edit my wrapper-jvm.conf file to set my architecture, and then the service started properly and registered with my instance.

set.SNC_JVM_ARCH=arm

jleon · ‎06-14-2017

I haven't received any error when I execute the start.sh in this way

sudo ./start.sh

It seems the MID Server is executed, but this one can't be reached by ServiceNow, also I don't see any error at the

agent/logs folder

Also I changed in the wrapper-jvm.conf file trying with this two values per process execution of the MID Server

set.SNC_JVM_ARCH=arm

set.SNC_JVM_ARCH=armv71

I followed all the steps proposed by Jonathan, and Robert about changing the architecture, without luck.

erichagstromnow · ‎06-27-2017

Sharing far and wide. Thanks for putting this all in a single doc. This symbolic links were the key for me.

Jon Ulrich · ‎08-10-2017

Good catch Robert! This setting fixed several errors I was receiving. I will add this configuration to the document.

Jon Ulrich · ‎08-11-2017

Jesus, are the log files generated and just no errors, or are the log files not even getting generated?

If the logs are there, can you please 1. Stop the service, 2. Delete the logs, 3. start the service and provide the wrapper.log and wrapper0.log.0 for me to review.

Gabriel Garc_a · ‎11-22-2017

Up and running!!!

Screen Shot 2017-11-22 at 4.34.11 PM.png

Jon Ulrich · ‎11-30-2017

Congratulations Gabriel! What are you going to build?

Gabriel Garc_a · ‎01-11-2018

It is just a lab to show the MID's versatility to our customers.

Chuck Tomasi · ‎02-09-2018

Quick note about this, the first apt-get may fail (as it did on my brand new Pi). You'll want to do

sudo apt-get update

to update the repositories first!

Chuck Tomasi · ‎03-15-2018

Important note: Be sure to validate your MID server.

I found that my Pi wasn't picking up REST requests in the ECC queue until I validated it. While I was able to retrieve logs and other basic "system" commands to the MID server, the RESTprobe entries were sitting in the outbound queue in a ready state. I thought it had to do with arm libraries and symlinks and what not, but it turns out that I just needed to open the MID server record on the instance and click "Validate" in the related links. After a few seconds, you should see the Validated field change to Yes, and outbound records start being processed.

Good luck!

Arnoud Kooi · ‎07-14-2018

Great article. I had to do 2 additional things:

chmod file: wrapper-linux-arm-32 to executable
run sudo ./start.sh to start the midserver (so with sudo)

Warren Shekyls · ‎08-16-2018

Not sure if anyone will answer this, but has anyone found a way to get the upgrade ui action from the mid server record to run and update the midserver on the raspberry pi.

When I try and click it, the agent logs from my midserver:

Unable to refresh packages. Unable to find version when calling 'user/lib/jvm/java-8-openjdk-armhf/jre/bin/java -version'. Received: openjdk version "1.8.0_171"

Andre Kosak · ‎08-29-2018

Hello @all

I like dockerizing everything. So i've created a few docker images for Raspberry Pi, that including a ready-to-use MID Server. Using these images would allow you to launch a MID server with minimum configuration within a few minutes.

On DockerHub you can find images with Kingston version (see tag names). There is also a Readme with instructions of launching a container with MID server. There are also images for "normal" CPUs.

Those image builds are automatic, so everyone can look through Dockerfiles and be sure there is nothing odd.

Known issues so far:

When sending "Upgrade" command to MID server, it receives the command, but does nothing. i assume the reason is, that the MID server is being launched via wrapper.
MID Server "London" doesn't want to start using the same approach.

Update: I forgot to say "thank you" to @Jon Ulrich. I used his guide from initial post to build the Dockerfile, that automates all the steps you should take. Thank you, Jon!

Jon Ulrich · ‎08-29-2018

Sorry, I have no solution for this 😞

Jon Ulrich · ‎11-28-2018

Update: Step 9, file does not exist on London files. I just created the file and put the line in the file without issue.

Gabriel Garc_a · ‎11-28-2018

Thanks Jon.

Lance D_Souza3 · ‎05-04-2019

If anyone would like to run a MID Server on a Raspberry Pi under version 2 you will require a wrapper built for that architecture i.e. armv6l

Place the attached files in the following location:

/opt/ServiceNow/agent/lib/libwrapper-linux-armhf-32.so

/opt/ServiceNow/agent/bin/wrapper-linux-armhf-32

It should then run.

This was confirmed running on the following MID build

madrid-12-18-2018__patch0-01-08-2019_01-17-2019_1433

Gabriel Garc_a · ‎05-04-2019

Great! Thanks Lance.

robpickering · ‎06-23-2019

THIS should be added to the original article. Thanks Lance!

Jon Ulrich · ‎06-24-2019

I have updated the original to reflect this, thanks for the suggestion 😄

Sharique Azim · ‎11-12-2019

I wonder if we really need all this ,can we not treat raspbian as another linux distro. and install plain and simple like in docs? Also, currently i am not able to install the midserver, installer.sh doesnt run or takes me to gui.

Btw i have arm 7l but somehow files are missing for me as mentioned in step 7:

sudo ln -s -r /servicenow/agent/bin/wrapper-linux-arm-32 /servicenow/agent/bin/wrapper-linux-armv7l-32

troubleshooting step

sudo ln -s -r /servicenow/agent/lib/libwrapper-linux-armhf-32.so /servicenow/agent/lib/libwrapper-linux-null-32.so
sudo ln -s -r /servicenow/agent/bin/wrapper-linux-arm-32 /servicenow/agent/bin/wrapper-linux-armv7l-

Update: Using as a linux disto did not work in new york version ,however i was able to run and scan earlier in london release in feb/march,2019

Update 2: I created a question for the same Install mid server on ARM7 linux(debian based) system /mid server wrapper files missing?

Sharique Azim · ‎11-22-2019

i was able to solve the issue, no other changes was required . i was not running from the right directory. Thanks for the useful post.

Paul135 · ‎03-08-2020

Hi

Using these instructions I got a New York version MID server running on a Pi 2. The auto-upgrade to Orlando failed so I tried a clean install, following the instructions again. However the MID server fails to run and I see this error message in the agent log:

more agent1.log.0
03/08/20 15:16:10 (409) WrapperStartStopAppMain WARNING *** WARNING *** Detected JRE version 1.8.0_40-internal does not meet the min requirement 1.8.0_161
03/08/20 15:16:11 (016) MIDServer Attempting to revert back to bundled JRE by updating wrapper-override.conf
03/08/20 15:16:11 (041) MIDServer The wrapper-override.conf file has been updated. Attempting to restart the MID
03/08/20 15:16:12 (432) WrapperListener_stop_runner WARNING *** WARNING *** Detected JRE version 1.8.0_40-internal does not meet the min requirement 1.8.0_16
1
03/08/20 15:16:12 (435) WrapperListener_stop_runner Attempting to revert back to bundled JRE by updating wrapper-override.conf
03/08/20 15:16:12 (452) WrapperListener_stop_runner The wrapper-override.conf file has been updated. Attempting to restart the MID

Looks like the wrong version of JRE is detected. Any ideas what I can do to resolve this?

Best Regards, Paul

Jon Ulrich · ‎03-12-2020

In step 8, do you have a newer version of JRE available in /usr/lib/jvm/?

If so update step 8.2 to point to that newer version.

Chuck Tomasi · ‎07-08-2021

Now that the MID server downloads are 64-bit only, has anyone successfully gotten this running on Ubuntu 20.04 or something? I keep running in to an error in the logs about getRecords failing. I've tried several things tweaking the config files, but still come back to that one failure. Just curious if anyone else has battled their way through the new security configurations. Here's a bit of my agent0.log.0

07/08/21 18:21:54 (686) MIDServer ExtensionContainer ThreadPool started with corePoolSize: 25, maximumPoolSize: 25, maximumQueueSize: 500
07/08/21 18:22:03 (397) MIDServer MIDCredentialsConfigProvider initialized with com.service_now.mid.creds.provider.standard.StandardCredentialsProvider
07/08/21 18:22:09 (059) MIDServer WARNING *** WARNING *** Socket error
07/08/21 18:22:09 (061) MIDServer SEVERE *** ERROR *** getRecords failed (Socket error)
07/08/21 18:22:09 (093) MIDServer WARNING *** WARNING *** MIDRemoteGlideRecord.query failed, retrying in 10 seconds
07/08/21 18:22:19 (861) MIDServer WARNING *** WARNING *** Socket error
07/08/21 18:22:19 (862) MIDServer SEVERE *** ERROR *** getRecords failed (Socket error)

Arnoud Kooi · ‎07-08-2021

No Pi at hand right now, but did you try PI OS 64bit?

https://downloads.raspberrypi.org/raspios_arm64/images/

Chuck Tomasi · ‎07-08-2021

I'll download it and try it this weekend. I'm not sure it's going to fix the issue as it look like (from the logs) that there is a negotiating issue between the instance and the MID server regarding keys/authentication. The server starts, begins talking to the instance, but doesn't get any further.

I may use a VM I have with my hosting provider just to prove I can do it and then come back to the Pi.

tblevins · ‎02-23-2022

I just got a San Diego MID running on a Pi4 using the 64bit Raspberry Pi OS.

I am cleaning up my documentation and will post updates shortly.

tblevins · ‎02-23-2022

Hi everyone, based on the steps above, these are the steps I took to get the 64bit MID in San Diego to run on a Raspberry Pi 4 using the 64 Bit Pi OS. I would expect that this should also work for Rome with some minor changes.

As the JRE the mid server comes with does not work on the arm archectature, you must install the ARM version of JRE

1. sudo apt-get install openjdk-11-jre
2. Create destination for your mid server files

1. sudo mkdir /servicenow
2. cd /servicenow
3. Figure out what mid server you need.

1. from your instance, navigate to Mid Server > Downloads in the left nav
2. Copy the download link for the Linux Zip file

Download mid server files into your servicenow directory

1. sudo wget https://install.service-now.com/glide/distribution/builds/package/app-signed/mid/2022/02/01/mid.sandiego-12-22-2021__patch0-hotfix1-02-01-2022_02-01-2022_2323.linux.x86-64.zip

Unzip your files. From here we will be modifying the /servicenow/agent directory to change things to work on the pie. Once this is done, the /servicenow/agent directory will be used to copy to each mid server you need

1. sudo unzip mid.[press tab to auto complete]

Figure out your exact processor architecture. Run the command and review the highlighted line

uname -a
root@raspberrypi:/usr/servicenow# uname -a
Linux raspberrypi 5.10.92-v8+ #1514 SMP PREEMPT Mon Jan 17 17:39:38 GMT 2022 aarch64 GNU/Linux

Setup the wrapper files matching your pi's architecture

sudo ln -s -r /servicenow/agent/bin/wrapper-linux-arm-64 /servicenow/agent/bin/wrapper-linux-wrapper-linux-aarch64-64

Edit wrapper override configuration to point to external JRE and change max memory

1. sudo nano /servicenow/agent/conf/wrapper-override.conf
2. Under External JRE uncomment the line for wrapper.java.command and update to the following
3. wrapper.java.command=/usr/lib/jvm/java-1.11.0-openjdk-arm64/bin/java
4. Under System resources uncomment wrapper.java.maxmemory, and set to a value that makes since for your Pi. My Pi has 1gb of memory, and I plan on running 2 mid servers so I chose 256 mb. I have been running it solid for a few days now without issue.
5. [Ctrl + x] exits, select [Y] save, enter for current file location

Edit the wrapper file to correct the processor architecture (Thanks to Robert Beeman for noting this)

0. sudo nano /servicenow/agent/conf/wrapper-jvm.conf
1. change set.SNC_JVM_ARCH=x86-32 to set.SNC_JVM_ARCH=arm64

Now copy the folder for your mid server and copy the agent into it

0. Setup the directory and move mid into it

0. sudo mkdir [your_mid_server]
1. sudo cp -r /servicenow/agent/ /servicenow/[your_mid_server]/agent/
2. cd [your_mid_server]/agent/

To configure the MID Server service, run the following command from the agent/bin folder as root and provide the required inputs.
```
./installer.sh
```
The installer.sh script takes the following inputs.

Instance URL

Enter the full URL of your instance, for example: https://mycompanyinstace.service-now.com

MID-Server Username

Enter the user name of the MID Server user that you already created. The MID Server user must have the mid_server role.

MID-Server Password

Set the password for the current MID Server user.

MID-Server Name

Set the name of the MID Server.

Proxy Server Information (optional)

mid.proxy.use_proxy

Enables the MID Server to use a web proxy to access the ServiceNow instance.

mid.proxy.host

Set this parameter to define the web proxy's host.

mid.proxy.port

Set this parameter to define the web proxy's port.

mid.proxy.username

If the web proxy requires a user name, set this parameter to define that username.

mid.proxy.password

If the web proxy requires a password, set this parameter to define that password.

To run a MID Server as a daemon service, the following properties are also required.

app_name

Set a unique name for the current MID Server

app_long_name

Set a unique long name for the MID Server.

run_as_user

Set the username to run the service as a non-root user.

Result

Once all the inputs are entered, the MID Server automatically runs as a daemon service and starts the service.

Gabriel Garc_a · ‎02-23-2022

WOW, that is fantastic.

tblevins · ‎02-24-2022

So it looks like I am getting an intermittent error. Sometimes when the mid service starts there is no issue and the service starts fine.

Others it doesn't completely start because I receive an error:

02/24/22 07:44:40 (763) StartupSequencer SEVERE *** ERROR *** Cannot read file: /usr/servicenow/auto-pi-tekneptunedevdemo/agent/��L��H��X��H�=��H��H�=��H��H�5�H�=�H��1��1�I��^H��H��PTL��H�
H�=%��f.�DH�P

the process is still running and it registers with the instance but shows down in servicenow.

Now this looks to be a binary that gets created when the service starts. If you delete it and restart the service it creates a new one.

I think this is a file name issue. there are times that the file name is too long. If it's not too long then the services starts just fine. If the name is created too long you get a Cannot read file error.

I have tried to chmod the file when it's too long and get

chmod: cannot access '/usr/servicenow/auto-pi-tekneptunedevdemo/agent/��L��H��X��H�=��H��H�=��H��H�5�H�=�H��1��1�I��^H��H��PTL��H�H�=%��f.�DH�P': File name too long

The only way I have been able to delete it is by it's inode.

"find . -maxdepth 1 -type f -inum 396638 -delete"

tblevins · ‎02-24-2022

The ASCII version of that name is

''$'\350\360\375\377\377''L'$'\211\357''H'$'\211\306\350\005\376\377\377\351''X'$'\377\377\377''H'$'\215''='$'\376\001\350\264\375\377\377''H'$'\205\300\017\204\323\376\377\377''H'$'\215''='$'\333\001\350\237\375\377\377''H'$'\205\300\017\204\276\376\377\377''H'$'\215''5'$'\306\001''H'$'\215''='$'\342\001''H'$'\211\302''1'$'\300\350\036\376\377\377\351\241\376\377\377''1'$'\355''I'$'\211\321''^H'$'\211\342''H'$'\203\344\360''PTL'$'\215\005\203\001''H'$'\215\r\f\001''H'$'\215''=%'$'\376\377\377\350\200\375\377\377\364''f.'$'\017\037\204\017\037''DH'$'\215\005''P'$'\023'

I am running ext4 which has a 255 byte limit but most filesystems have a 255 limit.

This is a 576 byte name... I am not sure how this is happening actually...

Kristy Merriam · ‎08-09-2022

You can get rid of that file automatically when the MID starts/restarts if you follow these steps:

Change the java command in wrapper-override.conf to /usr/bin/java
Create /opt/agent/cleangarbage.sh with these contents:
#!/bin/bash
rm /opt/agent/*DH*P*
Edit bin/mid.sh and add clear garbage here:
# List of files to source prior to executing any commands. Use ';' as delimiter.
# For example:
# FILES_TO_SOURCE="/home/user/.bashrc;anotherfile;../file3"
FILES_TO_SOURCE=/opt/agent/cleangarbage.sh

Appli · ‎04-15-2024

Hi, it does not work anymore in Washingtondc because this release does not contain wrapper-linux-arm-64.

lewismac · ‎07-10-2024

Hi all - an updated script for Washington DC can be found here !
@Lance D_Souza3 @Chuck Tomasi @Appli

https://www.servicenow.com/community/itom-forum/install-script-for-arm64-mid-server-on-washington-dc...