Project

General

Profile

Feature #1850

migrate osmo-gsm-tester from sysmocom internal jenkins to public jenkins

Added by laforge almost 2 years ago. Updated about 1 year ago.

Status:
Closed
Priority:
High
Assignee:
Target version:
-
Start date:
11/18/2016
Due date:
% Done:

100%

Spec Reference:

Description

We want to share the osmo-gsm-tester results with the general public, so let's migrate it from the sysmocom jenkins to the osmocom jenkins.

As part of that, the osmo-gsm-tester instance at sysmocom will have to be moved to a special "DMZ" network segment that is sufficiently isolated from the sysmocom company network, to ensure the osmocom jenkins has no access to sysmocom internal networks.


Related issues

Related to OsmoBTS - Feature #1849: osmo-bts-trx integration to osmo-gsm-testerClosed2016-11-18

Related to OsmoGGSN (former OpenGGSN) - Bug #2250: OpenGGSN requires to run as root for no apparent reasonClosed2017-05-10

Related to OsmoGSMTester - Feature #2251: run osmo-gsm-tester in user landClosed2017-05-11

History

#1 Updated by laforge almost 2 years ago

  • Related to Feature #1849: osmo-bts-trx integration to osmo-gsm-tester added

#2 Updated by neels over 1 year ago

  • Assignee set to neels
  • Priority changed from Normal to High

#3 Updated by neels over 1 year ago

  • Project changed from Cellular Network Infrastructure to OsmoGSMTester
  • Status changed from New to In Progress

A publicly reachable network segment is now available in the office.
Brief test shows: when connected to the publicly available net, the gsm-tester APU of the R&D setup registers as 10.9.25.101 (needs power cycle or network restart).
So far still connected to the in-office setup as before...

#4 Updated by neels over 1 year ago

The office-internal address for the gsm-tester R&D main unit is/will be 10.9.25.101. This exact address is already reachable from jenkins.osmocom.org.

Next todo: setup the osmo-gsm-tester main unit as a build slave in jenkins.osmocom.org.

#5 Updated by neels over 1 year ago

A build slave is now added to jenkins.osmocom.org, next up is setting it up to update and run the tester.

An open decision is which way to give permissions for things like:

- access to UHD
- tcpdump

maybe later:

- create tun for GGSN
- restart ofono service
- call uhubctl to power cycle modems

The build slave is currently running as jenkins. We could run it as root.

We could still run the jenkins build slave in user land, but grant permissions to launch the tester script as sudo without password. (Since we're also allowing permissions to update script, that's a free root pass there as well, safety wise).

The safest but most time consuming way is to give explicit permissions to the jenkins user as needed and document that -- various different steps specific to each type of permission needed.

I am tempted to just grant passwordless sudo for now. Am I allowed to do that? I assume that it safe enough in the sense that the sysmocom private network cannot be compromised by root access to the main unit -- right?

#6 Updated by laforge over 1 year ago

neels wrote:

An open decision is which way to give permissions for things like:

- access to UHD

that should be standard with any reasonable udev rules.

- tcpdump

If you instead use tshark, it will use dumpcap and the associated privilege separation, just like wireshark itself (which I presume you run as normal user on your laptop). dumpcap has CAP_NET_ADMIN and can thus sniff the packets, while the interpretation of the traffic runs inside the tshark (or wireshark) binaries as non-root. See e.g. https://superuser.com/a/319870

tshark even has a mostly compatible command line syntax, i.e. you can use "tshark -npi eth0 -w /tmp/foo.pcap" or the like.

- create tun for GGSN

should be possible with root creating a persistent tun device (like "tunctl -b -u laforge -g users -3 -t gtp0") once at start-up/boot time and then using that from a non-root openggsn. Have never tried this myself with OpenGGSN, but it's a standard feature of tun devices.

UPDATE: I quickly had a look at this. Seems like OpenGGSN wants to create the device and set the address, rather than being able to inherit/use an existing tun device. Should be rather trivial, I created #2250 for that.

- restart ofono service

not sure if/how that can be done by non-root using systemd-internal mechanisms. At least with sudo it's of course possible, and should be fairly secure as it's a single static systemctl command without any caller-supplied arguments, etc. (https://serverfault.com/a/772786)

- call uhubctl to power cycle modems

that might again be possible using udev rules, given that the quad-modem internal usb hub has a unique VID/PID, so a udev rule can simply chown the associated device to a given non-root user/group

The build slave is currently running as jenkins. We could run it as root.

We could still run the jenkins build slave in user land, but grant permissions to launch the tester script as sudo without password. (Since we're also allowing permissions to update script, that's a free root pass there as well, safety wise).

The safest but most time consuming way is to give explicit permissions to the jenkins user as needed and document that -- various different steps specific to each type of permission needed.

I am tempted to just grant passwordless sudo for now. Am I allowed to do that? I assume that it safe enough in the sense that the sysmocom private network cannot be compromised by root access to the main unit -- right?

I'm not overly worried here. It is a separate network segment. But then, I think in the general context of explaining our users how to configure more secure Osmocom setups, it might be worth to investigate and document the above-mentioned strategies to avoid having to run any osmocom software as root. I mean, if not even we are able to set our own system up that way, we cannot expect our users to do so, can we?

#7 Updated by laforge over 1 year ago

  • Related to Bug #2250: OpenGGSN requires to run as root for no apparent reason added

#8 Updated by neels over 1 year ago

  • Related to Feature #2251: run osmo-gsm-tester in user land added

#9 Updated by neels over 1 year ago

  • % Done changed from 0 to 90

The first successful trial has run on the public jenkins!
It was using code from my branch, containing the simplifications the jenkins build slave brings.
These need to pass review and be merged to master, but basically we're done here.

http://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/
http://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run/11/

Documentation to setup is also quite far, but not complete; on branch osmo-gsm-tester in the osmo-gsm-manuals

#11 Updated by laforge about 1 year ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)