Cellular Network Infrastructure

osmith wrote in #note-8:

That's untypical - do we want the programs to be able to change their own configs?

Some configs in /etc has non-root group. Assuming we also create osmocom group, we can have /etc/osmocom owned by root:osmocom while /etc/osmocom/osmo.bsc.cfg owned by osmocom:osmocom - that's similar to how transmission-daemon handle its config files.

laforge wrote in #note-6:

• modify /var/lib/osmocom (HLR + SMS databases) to be owned by that user

Once #4821 is resolved, this point will be done automatically: systemd autoadjust the state dir permissions to match unit's User=/Group= settings.

To make sure no project is left behind let's summarize the current state

Have I missed anything?

We may also want to run osmo-pcu with SCHED_RR.

This may be of use to list the projects: https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release#Dependency-graph

The example code adding user/group is available in https://gerrit.osmocom.org/c/osmo-hlr/+/29311

• clean install
• upgrade from previous ("root") version
• upgrade from previous ("user") version
• writing config file via telnet
• package uninstall
• piuparts:
  
sudo piuparts osmo-hlr_1.5.0_amd64.deb libosmo-gsup-client0_1.5.0_amd64.deb libosmo-mslookup0_1.5.0_amd64.deb libosmocore19_1.7.0_amd64.deb libosmogsm18_1.7.0_amd64.deb
...
PASS: Installation, upgrade and purging tests.


In general, possible source of problem is mix-n-match between "root" and "user" packages where "root" package is installed after the "user", overriding permissions and disabling read/write access to config files. I'm not sure if it's worth investing time into dealing with that - seems like coordinating release so root->user transition happens simultaneously is easier.

laforge wrote in #note-3:

• osmo-ggsn requires CAP_NET_ADMIN for setting up the gtp0/tun0 devices (unless this is done externally before starting it)

At least for tun0 device we can install corresponding .network file in addition to .service with proper User/Group settings.

How should we deal with .spec files? Shall I update those as well?

Creating user during package install is a distro-specific thing. Are there some other distros we care about?

What about OE?

msuraev wrote in #note-20:

How should we deal with .spec files? Shall I update those as well?

Creating user during package install is a distro-specific thing. Are there some other distros we care about?

What about OE?

As I understand, the systemd files get adjusted to expect the user to exist, and these systemd files are used in the rpms and on OE too. So we would need to make sure that the user exists there as well or else the systemd services wouldn't work there anymore.

Do we have some kind of hierarchy with regards to realtime scheduling? Like "osmo-pcu should have higher priority than osmo-trx" and such?

msuraev I personally use:
osmo-trx-uhd.cfg: "policy rr 18"
osmo-bts-trx.cfg: "policy rr 1"
osmo-pcu.cfg: "policy rr 1"

On Tue, Sep 20, 2022 at 09:11:35AM +0000, msuraev wrote:

Do we have some kind of hierarchy with regards to realtime scheduling? Like "osmo-pcu should have higher priority than osmo-trx" and such?

• osmo-trx should be higher than anything else
• osmo-bts-* below osmo-trx
• osmo-mgw below osmo-bts-*
• osmo-pcu below osmo-bts-*
• everything else isn't really timing critical.

laforge osmo-pcu now depends on getting FNs on time to calculate when to send stuff regarding scheduling, that's why I use same prio for osmo-bts and osmo-pcu.

Seems like it's not that obvious so the topic deserve ticket of its own - see #5687.

Tested osmo-hlr.rpm built via https://obs.osmocom.org/project/show/home:msuraev:rpmtest on OpenSUSE Tumbleweed. User:Group are created as expected, the permissions are properly set during install time. The .rpm support matches that of .deb

Tested with:

zypper ar https://people.osmocom.org/packages/home:/msuraev:/rpmtest/openSUSE_Tumbleweed/ osmo
zypper in osmo-hlr
getent passwd osmocom
getent group osmocom
ls -alh /etc/osmocom
ls -alh /etc/ | grep osmo


laforge wrote in #note-3:

• osmo-gbproxy requires CAP_NET_RAW if IPPROTO_GTP sockets are required for FR/GRE/IP

Looking through the code I couldn't find where this is used. It's also unclear why gbproxy would require it but OsmoSGSN and OsmoGGSN wouldn't. Could you please clarify?

msuraev wrote in #note-30:

laforge wrote in #note-3:

• osmo-gbproxy requires CAP_NET_RAW if IPPROTO_GTP sockets are required for FR/GRE/IP

Looking through the code I couldn't find where this is used. It's also unclear why gbproxy would require it but OsmoSGSN and OsmoGGSN wouldn't. Could you please clarify?

osmo-gbproxy is the only network element that "officially" supports Gb over frame relay over E1. We use it to convert from legacy RAN/BSS Gb/FR/E1 to Gb/UDP/IP, so that the SGSN can use normal Gb/UDP/IP.

laforge wrote in #note-31:

osmo-gbproxy is the only network element that "officially" supports Gb over frame relay over E1. We use it to convert from legacy RAN/BSS Gb/FR/E1 to Gb/UDP/IP, so that the SGSN can use normal Gb/UDP/IP.

How does that look like to Linux? Some specific network interface?

And how do we test it?

Would be nice to try and ensure it works instead of simply slapping CAN_NET_RAW and hoping it's enough.

hdlcX net device. There's a wiki page documenting this, including how to set up a virtual loop back device like we use in Jenkins testing. libosmogb simply uses AF_PACKET sockets, so CAP_NET_RAW should do the trick.