Introduction

The audience for this article are teachers wanting to use Cisco equipment to teach a computer networking course. Most of it is not applicable in a real environment.

This article is for people that are already familiar with using real equipment (switches, routers) for a computer networking course, and have a basic understanding of how to configure a Cisco equipment.

It assumes that the problem of how to access the equipment at any given moment to configure it is already solved. In my lab, we use a terminal server for that.

Some of this information might relate to old and obsolete equipment.

Switches

vtp mode transparent
vtp mode off

no cdp enable

no cdp run

switchport mode trunk
switchport nonnegotiate

switchport mode access

no keepalive

Why OpenRC

There are a few reasons. First, I’m not perfectly happy with systemd. It’s OK if you do nothing with it, but at some point, I had to write a specific service, and the fact that systemd does everything on your machine (hostnamed, resolvd, etc) makes it hard to just tweak just a few things. Also I don’t like journald, and I hate socket activations.

Now I decided between OpenRC and runit by looking at their features, and I like the fact that OpenRC uses dependencies for init scripts. It doesn’t come with user services, more on that later.

Installation

To make the installation as easy as possible, I booted from a rescue usb stick, chrooted into my system, and typed

aptitude install openrc

that’s it ! I tried before on virtual machines to update inside a running machine, it proved to be a mistake. Booting from a rescue CD/usb stick is much easier

The end result

Even without systemd, you will still see some systemd files and applications:

• the udev binary is actually called systemd-udevd, because udev is now part of systemd. I have nothing against udev, and replacing it seems a bit cumbersome, so I’ll keep it for now

• the libsystemd0 package is still installed. A few years ago it was possible to replace it with libelogind0 (ABI compatible) but the new elogind depends on libsystemd0 and conflicts with libelogind0.

An important thing to note is that getting rid of systemd does not get rid of code written in conjunction with systemd. Typically, udev is part of systemd, elogind is a fork of part of systemd…

A few commands

To know the list of services that are currently run:

rc-status

Start/Stop a service

/etc/init.d/NAME [start|stop]
rc-service NAME [start|stop]

Remove a service from startup

rc-update del NAME

User services

systemd does not only manage system services, but also user services. openrc doesn’t. It turns out that there are a ton of user services that are run when someone logs on a machine: Typically, on my main desktop, 15 services (!) are launched. Some of them are pretty important and almost mandatory. Typically, I suspect that users that have a bad experience with openrc typically didn’t realize they’d need to add some users services.

A big one is pipewire, if you want to have sound. Other services are largely irrelevant, with the exception of dbus

root% cat /etc/xdg/autostart/pipewire.desktop
[Desktop Entry]
Name=PipeWire
Comment=Start PipeWire
Icon=pipewire
Exec=pipewire
Terminal=false
Type=Application
NoDisplay=true
root% cat /etc/xdg/autostart/pipewire-pulse.desktop
[Desktop Entry]
Name=PipeWire pulse
Comment=Start PipeWire pulse
Icon=pipewire
Exec=pipewire-pulse
Terminal=false
Type=Application
NoDisplay=true
root% cat /etc/xdg/autostart/wireplumber.desktop 
[Desktop Entry]
Name=Wireplumber
Comment=Start Wireplumber
Icon=pipewire
Exec=wireplumber
Terminal=false
Type=Application
NoDisplay=true

if [ -n "$SSH_CLIENT"  ]; then
  bus_id=$(cat /etc/machine-id)-0
  dbus_file="$HOME/.dbus/session-bus/${bus_id}"
  if [ -r "$dbus_file" ]; then
      source "$dbus_file"
      export DBUS_SESSION_BUS_ADDRESS
      export DBUS_SESSION_BUS_PID
      export DBUS_SESSION_BUS_WINDOWID      
  fi
fi

Zones

It’s good to think of zones as a entirely new operating system, completely isolated from the main system: the only thing they have in common with the original system is that they run on the same computer, but they use different filesystems, different PIDs, etc. This is really apparent from the fact that the first thing one does when installing a zone is configuring it as one whould essentially configure a new system (what’s its name, what’s its timezone, etc). In this sense, I would say the closest similarity in the Linux namespace world is LXC/LXD or Incus and certainly not docker/podman.

It is still possible to share some things with the zones: some filesystems, or some network cards (or rather, a virtual version of your network card).

It is difficult to discuss Solaris without discussing zfs. The revolutionary filesystem makes it able to create volumes (partitions) on the fly. All zones in what follows will each use a different volume, created inside the /zones directory

zfs create -o mountpoint=/zones rpool/zones

Installation

Using a zone takes 4 steps:

• Configure the zone
• Install the zone
• Boot the zone
• Access the zone

Here is a typical configuration of a zone, using the zonecfg command. This is an interactive command that can also be used noninteractively

solaris% zonecfg -z mypc
Use 'create' to begin configuring a new zone.
zonecfg:mypc> create
create: Using system default template 'SYSdefault'
zonecfg:mypc> set zonepath=/zones/mypc
zonecfg:mypc> info
zonename: mypc
zonepath: /zones/mypc
brand: solaris
anet 0:
        linkname: net0
        configure-allowed-address: true
zonecfg:mypc> exit
solaris%        

The zone is named mypc. The root of the filesystem is located in /zones/mypc. The info command tells us that this new zone will have a network card called net0 that will be configured automatically.

We can now install the zone:

solaris% zoneadm -z mypc install
The following ZFS file system(s) have been created:
    rpool/zones/mypc
Progress being logged to /var/log/zones/...
       Image: Preparing at /zones/mypc/root.

 Install Log: /system/volatile/install.5551/install_log
 AI Manifest: /tmp/manifest.xml.50GKxb
  SC Profile: /usr/share/auto_install/sc_profiles/enable_sci.xml
    Zonename: mypc
Installation: Starting ...

        Creating IPS image
Retrieving catalog 1/1 solaris ...
...
DOWNLOAD                                PKGS         FILES    XFER (MB)   SPEED
library/expat                         45/247    6184/39850   55.1/301.2  4.4M/s
...
Installing new actions                   12232/62305
...
Installation: Succeeded
 done.

        Done: Installation completed in 241.426 seconds.


        Next Steps: Boot the zone, then log into the zone console (zlogin -C)
        
              to complete the configuration process.
solaris%

This is an excerpt of the install procedures. As is apparent from the capture, it looks very much like a full OS is installed: a list of packages to install is created, and then installed.

We can now boot the system, then log into the system:

solaris% zoneadm -z mypc boot
solaris% zlogin -C mypc

As one can expect when starting a new OS, here is the first screen that we see: a configuration screen:

We then get after a few steps to a login prompt, where we can test our new system. (Hint: type ~. to close the connection to your brand new OS and go back to the original one).

This new system sees nothing of the original one. From the original system, we can access via /zones/mypc/root to the root filesystem of this particular zone, and we can see the virtual network card, installed on top of the existing one:

solaris% dladm
LINK                    CLASS      MTU    STATE    OVER
net0                    phys       1500   up       --
mypc/net0               vnic       1500   up       net0

Mounting filesystems

It is possible to mount a filesystem from the host (technical term is “from the global zone”) for it to be accessible to another zone:

solaris% zonecfg -z mypc
zonecfg:mypc> add fs
zonecfg:mypc:fs> set type=lofs
zonecfg:mypc:fs> set special=/shared
zonecfg:mypc:fs> sed dir=/usr/shared
zonecfg:mypc:fs> set options=ro
zonecfg:mypc:fs> end
zonecfg:mypc> exit

In this case, the directory /shared from the global zone will be shared read-only as the directory /usr/shared in the zone mypc. This doesn’t work if the zone is currently running, and you have to reboot it (zoneadm shutdown, zoneadm boot) for it to work.

Isolated networks

Using the concept of virtual network interfaces, we can create two zones, with two different IPs, that can communicate with each other, but not with the rest of the world.

First we create (in the global zone) a bridge, and two network interfaces that are connected to this bridge:

solaris% dladm create-etherstub bridge1
solaris% dladm create-vnic -l bridge1 eth1
solaris% dladm create-vnic -l bridge1 eth2

Now we need to create two zones: the first one will use eth1, the second one eth2. While creating the zones, we also need to remove the default internet interface:

solaris% zonecfg -z pc1
zonecfg:pc1> set zonepath=/zones/pc1
zonecfg:pc1> remove anet
zonecfg:pc1> add net
zonecfg:pc1:net> set physical=eth1
zonecfg:pc1:net> end
zonecfg:pc1> info
zonename: pc1
zonepath: /zones/pc1
brand: solaris
net 0:
        physical: eth1
zonecfg:pc1> exit

and the same for pc2.

Now we only need to fix the IP addresses when booting the zone for the first time :

or do it afterwards:

pc1% ipadm create-ip eth1
pc1% ipadm create-addr -T static -a local=10.0.0.1/24 eth1/v4

From the global zone, here is how the network interfaces appear:

solaris% dladm
LINK                    CLASS      MTU    STATE    OVER
net0                    phys       1500   up       --
bridge1                 etherstub  9000   unknown  --
eth1                    vnic       9000   up       bridge1
eth2                    vnic       9000   up       bridge1
pc1/eth1                vnic       9000   up       bridge1
pc2/eth2                vnic       9000   up       bridge1

Next Time

Next Time, we examine FreeBSD jails.

Plan 9

Plan 9 adheres to the Unix philosophy that “everything is a file” and put it to the extreme (note that Plan 9 is not an Unix, even though it might look very similar at first).

Not only is everything a file (including most devices), but every communication with the files are done using open/read/write, and there is no use for peculiar ioctl.

For instance, to connect to a TCP server, you just need to open the file /net/tcp/clone to create a tcp connection, and read a number N from it. Next you can write connect 10.0.0.1!80 to the file /net/tcp/N/ctl to connect to the given address, and then communicate with the distant server using the file /net/tcp/N/data. This can be scripted of course.

Similarly, to kill a process, one can just do echo kill > /proc/PID/ctl.

Another peculiarity is that the filesystem is per process. Every process can mount/bind a volume and it will only be seen from that process. For instance, mounting a usb key in one terminal does not mean the usb key will be seen in another.

Mount namespaces

This means it is particularly simple to have a process with a completely different filesystem than the other processes (technically that is always the case in plan 9 !).

For instance, suppose that your HOME directory is /usr/glenda. By typing the following command in a terminal:

bind -c /some_directory /usr/glenda

/usr/glenda now contains the content of /some_directory and your process cannot see the original files in /usr/glenda anymore.

There is a small problem however. Using the command ns, the user can see all mounted volumes, and will see:

term% ns
bind '#c' /dev
bind '#d' /fd
...
bind -c /some_directory /usr/glenda

so the user can do

unmount /usr/glenda

to see the original files !

If you want to protect the files correctly, the best is to create another root entirely, without the executable bin/unmount. Or, at the very least, you should also remount /bin to exclude the file bin/unmount.

Network namespaces

Mounting different directories as /net, it is easy to have different processes see different network stacks.

In the following I will illustrate this with a recipe to have two environments that thinks they have IP 10.0.0.1 and 10.0.0.2 respectively on two different network cards.

Here are the commands. First we create two empty directories /tmp/net.1 and /tmp/net.2 and associate each of them with a virtual network card.

mkdir /tmp/net.1
mkdir /tmp/net.2

bind -a '#l1:sink ea=001122334402' /tmp/net.1
bind -a '#I1' /tmp/net.1
bind -a '#l2:sink ea=deadbeef0011' /tmp/net.2
bind -a '#I2' /tmp/net.2

Intuitively, the first bind adds the network interface /ether1 (resp. /ether2) to the /tmp/net.X directory. The second binds adds the layer 3/4 services (IP/ICMP/UDP/TCP) for that network interface. The sink argument says the network card is virtual. The ea argument is for the ethernet address.

Now we build a bridge, and connect both interfaces to the bridge:

bind -a '#B1' /net

echo 'bind ether port1 0 /tmp/net.1/ether1' > /net/bridge1/ctl
echo 'bind ether port2 0 /tmp/net.2/ether2' > /net/bridge1/ctl

and we add IP addresses to these interfaces:

ip/ipconfig -x /tmp/net.1 ether /tmp/net.1/ether1 10.0.0.1 255.255.255.0
ip/ipconfig -x /tmp/net.2 ether /tmp/net.2/ether2 10.0.0.2 255.255.255.0

Now we want to open two terminals: one where the network is given by what is currently in /tmp/net.1 and the other by what is currently in /tmp/net.2. But remember, all these commands were written in one terminal (say, terminal A) and the filesystemsa are per process, so terminals other than terminal A won’t see what are in these directories.

So we can’t do bind /tmp/net.1 /net on one process, as their /tmp/net.1 directory is empty.

To do that correctly, we will use srvfs, as a relay file server. Everything is /srv is seen everywhere, so we will put our two configurations directories inside /srv with the commands

srvfs pc1 /tmp/net.1
srvfs pc2 /tmp/net.2

This creates directories /srv/pc1 and /srv/pc2.

Now, on two different terminals, we can do mount /srv/pc1 /net and mount /srv/pc2 /net, and these two different terminals will use the two virtual interfaces as their default interfaces. You can then try ip/ping 10.0.0.2 from the first terminal.

The same remark as the last section applies: each terminal can still do unmount /net to recover the original network interface. Some more work has to be done to prevent the use of unmount.

Remarks

There were a few namespace things that I wasn’t able to do. Some of them, after some thinking, might not make sense given how the OS is structured. In particular, I would like to have terminals with different PID namespaces (and therefore different /proc namespaces). I don’t see anything that would break with that in place, but I certainly didn’t look closely enough.

Next Time

Next Time, we examine Solaris zones.

Docker

Assuming you’re in the docker group, you can install sage with the command

docker pull sagemath/sagemath

You can then run sage with one of the following commands (sage or jupyter)

docker run -it --rm sagemath
docker run --rm -p 8888:8888 sagemath/sagemath sage-jupyter

(add -it to the last command if you want to be able to quit it from the command line)

Now suppose you want to share the directory my_directory with sage/jupyter.

You can do it this way:

docker run --rm -p 8888:8888 -v my_directory:/home/sage/notebooks sagemath/sagemath sage-jupyter

Podman

podman is my preferred solution, because it doesn’t require you to be root.

The first commands are almost identical:

podman pull docker.io/sagemath/sagemath
podman run -it --rm sagemath
podman run --rm -p 8888:8888 sagemath sage-jupyter

The difficulty is how to share a directory.

The obvious solution would be:

podman run -it --rm -p 8888:8888  --userns=keep-id -v my_directory:/home/sage/notebooks:Z sagemath sage-jupyter

but it doesn’t work with the default storage driver. The --userns=keep-id option requires essentially podman to do a chmod -R on the whole volume. However, with the overlay driver, podman can’t do it efficiently and instead needs to copy all of the files again. It takes a thousand of minutes.

There are two solutions.

[storage]
  driver = "overlay"
[storage.options.overlay]  
  mount_program=  "/usr/bin/fuse-overlayfs"

podman run -it --rm -p 8888:8888  --userns=keep-id -v my_directory:/home/sage/notebooks:Z sagemath sage-jupyter

podman run -it --rm -p 8888:8888  --storage-opt overlay.mount_program=/usr/bin/fuse-overlayfs --userns=keep-id -v my_directory:/home/sage/notebooks:Z sagemath sage-jupyter

podman run -it --rm -p8888:8888  --user 0 -v /home/ejeandel/sage:/home/sage/notebooks:Z sagemath sage-jupyter --allow-root

Installation of Citrix Workspace App

• Go to https://www.citrix.com/downloads/workspace-app/linux/workspace-app-for-linux-latest.html and install the application

• On my Debian system, I also needed to install the package libwebkit2gtk-4.0-37 for it to work

• Copy the certificate for Comodo from firefox to Citrix:

cp /usr/share/ca-certificates/mozilla/Comodo_AAA_Services_root.crt /opt/Citrix/ICAClient/keystore/cacerts/AAA.pem
/opt/Citrix/ICAClient/util/ctx_rehash 

• I have tried taking directly the ca-ul.pem certificate instead, but it seems to be different from the virtul certificate.

Launch

Just launch

/opt/Citrix/ICAClient/selfservice

Put virtul.univ-lorraine.fr as the server. You should probably configure the app so that your HOME directory appears inside the virtual machine, by clicking on settings.

Edges and angles in TikZ

I will explain here what happens when you write

\draw (0,0) edge[in=90,out=60] (5,0);

This draws a curvy edge between the points and , in such a way that the curve leaves the first point with angle 60 degrees, and goes into the second point with angle 90 degrees.

Internally, this is converted into a Bezier curve, that starts at the first point, and ends at the second point. The only thing that needs to be specified are the control points.

Here is how they are computed:

• The distance between the two points is computed.
• This distance is multiplied by 255/256 then by 0.3915 to obitan a number
  
• The two control points for the Bezier curve are then defined in the following way:
  • The first control point is at distance d and angle out from the first point.
  • The second control point is at distance d and angle in from the second point

The first multiplication of the distance by 255/256 is due to the way the distance is computed. Assuming and both are positive:

• The ratio is first computed, then multiplied by 65536 and divided by to obtain the number
• is multiplied by 16, then divided by , then multiplied again by .

The complete operation is therefore

Again, this is done by steps, in fixed point arithmetics, so the final result might be slightly different.

\draw (0,0) edge[in=-90,out=0] (1,1);

Source

The code that converts angles into control points is in the file generic/pgf/frontendlayer/tikz/libraries/tikzlibrarytopaths.code.tex of tikz, more precisely in the function \tikz@to@compute@distance@main.

Pandoc

Pandoc can directly convert .bib files to .html with the command

pandoc -C -f bibtex toto.bib --csl=mine.csl -t html

If we launch pandoc on the previous file, we obtain the following output:

Style files for pandoc/citeproc are in the CSL format. (The file mine.csl I used is customized from the ACM format) The result is good if to be included in an article, but not perfect for a webpage. I found it difficult in particular to customize some parts of the output, in particular the href parts, and the abstract parts.

Bibtex2html

Another solution is to use bibtex2html.

bibtex2html -nobibsource -nokeywords -s dsgplain -linebreak -d -r -dl -nodoc -noheader     -nf url "DL" -nofooter publis.bib

Here is the output:

[1]

Emmanuel Jeandel. HTML and Bibtex. Theory of HTML, 12:12–49, 2023.
[ DL ]

HTML is good

[2]

Emmanuel Jeandel and Jeannot Lapin. Is Bibtex good. In International Colloquium on Bibtex (ICB), 2020.
[ DL ]

This is an abstract

The -dl option is to use HTML DL lists rather than tables, which makes the output look nicer imho. The -d -r options are to sort by date in reverse order.

The output is nicer and that’s what I have been using for some time. The dsgplain.bst file is very standard, and any other bibtex style would have worked really. I was not completely happy with the DL lists, but the result is customizable. I didn’t find a way to put class on every tag so that I could customize it entirely, but it’s still quite good.

A silly attempt

Another possible solution is to actually create a .bst file for bibtex in such a way that the output is directly HTML. Once you understand how .bst files work (it uses reverse polish, à-la forth and postscript) , this is not hard.

I didn’t choose this solution for one reason: my .bib files might contain latex commands (for accents and math) and using this solution means the latex commands would be put in the HTML verbatim. I realized this very soon and didn’t pursue this solution.

The final result

bibtex is very good at producing .tex files from .bib. I realized that the best solution in my case was to use the following workflow:

• Convert the .bib into a .tex (actually a .bbl) using bibtex with a customized .bst (bibtex style file)
• Convert the .tex into .html using pandoc

I use the following script to do all the work:

#!/bin/bash

X=${1%.bib}
echo  "
\select@language{english}
\citation{*}
\bibstyle{dsgplain}
\bibdata{$X}" > ${1%.bib}.aux
bibtex ${1%.bib}
pandoc -f latex  ${1%.bib}.bbl -o ${1%.bib}.html
rm ${1%.bib}.aux
rm ${1%.bib}.blg

Here is the result:

1. Emmanuel Jeandel. HTML and Bibtex. Theory of HTML, 12:12–49, 2023 [DL]

   Abstract

   HTML is good

2. Emmanuel Jeandel and Jeannot Lapin. Is Bibtex good. In International Colloquium on Bibtex (ICB), 2020 [DL]

   Abstract

   This is an abstract

Here is the .bst file I use for this result.

Finishing notes

The last solution is actually not what I’m using. My workflow is a bit more complex: As I use quarto for my webpage, I decided to convert the .tex into markdown using pandoc, and then process the markdown with quarto.

This made me able to have a presentation of abstracts that is better than the previous example and can be collapsed (see my publications page on the top).

Something tricky happened however. When you convert the first bibtex entry above in markdown, here is what you obtain:

1.  Emmanuel Jeandel. **HTML and Bibtex**. *Theory of HTML*, 12:12--49,
    2023 [\[DL\]](http://a.real.url)

    Abstract

    :   HTML is good

Notice that the second line starts with 2023. If I had put a period at the end of the year (to obtain 2023. instead of 2023), this could have been interpreted by pandoc/quarto to represent the beginning of a numbered list !

I still haven’t found a satisfying solution to this problem, outside of hacks.

Note

Many of the configuration below needs to know your inria password. I personally use secret-tools to connect with keepassxc

The line

secret-tool lookup pass zimbra

is how I obtain my zimbra password kept in keepassxc for instance.

Replace this with your preferred method to obtain passwords.

Mail user Agent (mutt)

My preferred MUA is mutt

Here is the configuration I use.

Common configuration:

mailboxes 'imaps://zimbra.inria.fr:993/' 'imaps://imap.univ-lorraine.fr:993/'

For Loria:

set my_pw_inria=`secret-tool lookup pass zimbra`
account-hook imaps://zimbra.inria.fr:993/ 'set imap_user=mynickname imap_pass=$my_pw_inria'
folder-hook imaps://zimbra.inria.fr:993/ my_hdr From: myfirstname.mylastname@loria.fr
folder-hook imaps://zimbra.inria.fr:993/ 'set record=imaps://zimbra.inria.fr:993/Sent'

And for UL:

set my_pw_ul=`secret-tool lookup pass ul`
account-hook imaps://imap.univ-lorraine.fr:993/ 'set imap_user=mynickname imap_pass=$my_pw_ul'
folder-hook imaps://imap.univ-lorraine.fr:993/ my_hdr From: myfirstname.mylastname@univ-lorraine.fr
folder-hook imaps://imap.univ-lorraine.fr:993/ 'set record=imaps://imap.univ-lorraine.fr:993/Sent'

Mail Transfer Agent (msmtp)

My preferred MTA is msmtp

Here is the configuration for loria:

account default
host smtp.inria.fr
from myfirstname.mylastname@loria.fr
port 587
auth on
user mynickname
passwordeval "/usr/bin/secret-tool lookup pass zimbra"
tls on

and for UL:

account ul
host smtp.univ-lorraine.fr
from firstname.lastname@univ-lorraine.fr
port 587
auth on
user mynickname@univ-lorraine.fr
passwordeval "/usr/bin/secret-tool lookup pass ul"
tls on

and of course the mutt-msmtp interaction in the mutt configuration file:

set sendmail="/usr/bin/msmtp"

Calendar

My software of choice for calendars is khal. It essentially pilots a local directory of icalendars, so configuring it to work with the Loria calendar essentially amounts to explain how to synchronize the local directories with the zimbra calendar, which is done with vdirsyncer.

There is nothing specific in khal about my setup, everything happens in vdirsyncer.

Configuration is split into three parts: the Loria zimbra calendar, the UL zimbra calendar, and the ADE calendar.

For the Loria zimbra calendar:

[storage zimbra]
type = "caldav"
url = "https://zimbra.inria.fr/dav/firstname.lastname@loria.fr"
username = "nick"
auth = "basic"
password.fetch = ["command", "secret-tool", "lookup", "pass", "zimbra"]

[storage zimbra_local]
type = "filesystem"
path = "~/.calendars/zimbra"
fileext = ".ics"

[pair zimbra_pair]
a = "zimbra"
b = "zimbra_local"
conflict_resolution = "a wins"
collections = ["Calendar"]

For the UL zimbra calendar, replace all instances of zimbra by ul and the url is now: https://mail.univ-lorraine.fr/dav/firstname.lastname@univ-lorraine.fr

Finally, for the ADE calendar, you first need to know its address:

• Click on monade
• Click on the “Export Agenda button” on the top right
• Click on “Generate URL”
• Change the dates in the URL to be from early september to late august.

Now you can configure the calendar:

[storage ade_remote]
type = "http"
url = "https://adeical.univ-lorraine.fr/..."

[storage ade_local]
type = "filesystem"
path = "~/.calendars/ade"
fileext = ".ics"

[pair ade_pair]
a = "ade_remote"
b = "ade_local"
conflict_resolution = "a wins"
collections = null

Note that you usually need to change the URL every year.

The usage of vdirsyncer is simple: just vdirsyncer discover the first time, then vdirsyncer sync everytime you want so sync.

NextCloud (UL)

You can use the official nextcloud server to connect to the University Nextcloud of course. You can also use rclone

• First launch BUL. In Sécurité, you can add an “application password” that will be specific to rclone

• Then you can launch rclone config:

  • Select WebDav then nextcloud
  • The URL to enter is https://bul.univ-lorraine.fr/remote.php/webdav

Printer

Two notes:

• You don’t need to install a cups server (but you need a cups client)
• You don’t need cups-browsed

The easiest way to make printing works is to create a file ~/.cups/client.conf with the following line

ServerName cups-nge.inria.fr:631/version=1.1

And that’s it. It’s also useful (but not mandatory) to configure ~/.cups/lpoptions with:

Default printer-bw-nge Duplex=DuplexNoTumble OptionDuplex=True PageSize=A4

so you don’t have to specify the printer each time.

Remarks

• There are a few tutorials for doing this on the net. If you look at old posts, they will usually be more complicated because adb shell used to do CR/LF conversions which means your files and commands will become mangled while passing through adb. This is not a problem anymore.

Creating the namespaces

Here is how to do it, in a shell, first write the command

unshare -r

So that you are “root” in the shell.

From this shell, open two new shells, and in each of them write the command

unshare -n

What we have done this way is create three namespaces:

• A user namespace, which makes you root
• Two network namespaces, inside the user namespace

This means you now have two network namespaces, and the same user is root on both.

Creating the namespaces (alternative)

If you’re on a linux system where you don’t really know how to launch a terminal from inside another terminal (because you’re using a desktop environment), there is another way to obtain the same result

On a first shell, write

unshare -rn
echo $$

On the second shell:

nsenter --preserve-credentials --user -t PID
unshare -n

where PID is the PID of the first shell

Creating the interfaces

The two namespaces are anonymous. To reference an anonymous namespace, you can reference it by the PID of one application in that namespace. Therefore we will execute the command

echo $$

in both shells to know the PID of the bash process (or your favorite shell, if it is not bash)

In the following, FIRST_PID is the PID of the first bash process, and SECOND_PID the PID of the second bash process.

Now in the first shell, type

ip link add veth00 netns FIRST_PID type veth peer veth11 netns SECOND_PID

This will create an interface veth00 in the first namespace (the first shell) that is linked to the interface veth11 in the second namespace.

Now you can add IP to these interfaces, put them up, and do some networking!

firstshell# ip addr add 10.42.0.2/24 dev veth00
firstshell# ip link set veth00 up

secondshell# ip addr add 10.42.0.3/24 dev veth11
secondshell# ip link set veth11 up

And that’s it! You can test everything is working as it should by pinging the machines. You can also try to see the traffic using wireshark, remember to launch wireshark from inside one of the two shells, and to use the interfaces veth00 and veth11.

A script

The following script can be used to automate everything. It supposes that you have tmux on your PC, as well as x-terminal-emulator:

#!/usr/bin/bash

tmux  new-session -d -s master -n 1 "unshare -rn bash"
PIDMASTER=$(tmux list-panes -t master:0 -F '#{pane_active} #{pane_pid}' | cut -f 2  -d " ")

tmux  new-session -d -s reseaux0 -n 1 "nsenter --preserve-credentials --user -t $PIDMASTER unshare -n"
tmux  new-session -d -s reseaux1 -n 1 "nsenter --preserve-credentials --user -t $PIDMASTER unshare -n"

PID0=$(tmux list-panes -t reseaux0:0 -F '#{pane_active} #{pane_pid}' | cut -f 2  -d " ")
PID1=$(tmux list-panes -t reseaux1:0 -F '#{pane_active} #{pane_pid}' | cut -f 2  -d " ")

nsenter --preserve-credentials --user -n -t $PID0 sh -c "ip  link add veth00 netns $PID0 type veth peer veth11 netns $PID1"

nsenter --preserve-credentials --user -n -t $PID0 sh -c "ip addr add 10.42.0.40/24 dev veth00" 
nsenter --preserve-credentials --user -n -t $PID0 sh -c "ip link set veth00 up" 
nsenter --preserve-credentials --user -n -t $PID0 sh -c "ip link set lo up" 

nsenter --preserve-credentials --user -n -t $PID1 sh -c "ip addr add 10.42.0.50/24 dev veth11" 
nsenter --preserve-credentials --user -n -t $PID1 sh -c "ip link set veth11 up" 
nsenter --preserve-credentials --user -n -t $PID1 sh -c "ip link set lo up" 

tmux send-keys -t reseaux0:0  PS1=\'pc0:'\w\$'\' Enter
tmux send-keys -t reseaux1:0  PS1=\'pc1:'\w\$'\' Enter

tmux send-keys -t reseaux0:0 C-l
tmux send-keys -t reseaux1:0 C-l

x-terminal-emulator -e "tmux attach -t reseaux0"&
x-terminal-emulator -e "tmux attach -t reseaux1"&
x-terminal-emulator -e "tmux attach -t master"&

Remarks

• If you try to ping 10.42.0.2 from the firstshell, this will not work, because this implicitely uses the lo interface that is down. If you want to be able to ping yourself, you can do ip link set lo up.

• The interface is only visible in the shell if they share the same namespace. When the previous command is typed, veth00 is visible in the first shell, but veth11 is visible only in the second shell.

• It won’t surprise anyone that most of these features are very useful to make containers. The important thing here is that we can do this in user mode. This does not provide a real sandboxing, but it is very useful if you just want to test some small networking scripts as a user which is not root.