jails Installing FreeBSD5 in a jail in FreeBSD14

I would like to test how far in time can Jails keep old versions and I am trying to deploy a FreeBSD5 (the first release supporting amd64) in a jail being the host FreeBSD14.

This host has several FreeBSD14 jails and they work without issues. I have tried to follow the same procedure but being FreeBSD5 so legacy/ancient release I am stuck at the network configuration.

This is what I have done so far:
- I have downloaded the base system from http://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/amd64/5.5-RELEASE/base/
- My jail will be named freebsd5
- I have installed the base for FreeBSD5 into /jails/containers/freebsd5 using the base install.sh script and setting the corresponding environment variable to that point.
- I have added a new user via chroot and adduser.
- I have created an empty /etc/fstab file
- I have copied /etc/resolv.conf from the host to the jail
- I have created the /etc/jail.conf.d/freebsd5.conf file -IP is mask- in the very same way than for my regular working FreeBSD14 jails:
Code:
freebsd5 {
 
  # STARTUP/LOGGING
  exec.start      = ""; # rc to run after networking is up
  exec.stop       = "/bin/sh /etc/rc.shutdown";
  exec.consolelog = "/var/log/jail_console_${name}.log";

  # PATH/HOSTNAME
  path = "/jails/containers/${name}";

  # DEVFS
  allow.raw_sockets;
  exec.clean;
  mount.devfs;
  devfs_ruleset = 5;
 
  # MOUNTS 
  allow.mount = true;
  allow.mount.nullfs = true;

  # VNET/VIMAGE
  vnet;
  vnet.interface = "${epair}b";
 
  # NETWORK
  host.hostname = "${name}";
  $ip = "x.x.x.29/24";
  $gateway = "x.x.x.1";
  $bridge = "bridge0";
  $epair = "epair29"; 

  # STARTUP/STOP
  exec.prestart  = "/sbin/ifconfig ${epair} create up";
  exec.prestart += "/sbin/ifconfig ${epair}a up descr jail:${name}";
  exec.prestart += "/sbin/ifconfig ${bridge} addm ${epair}a up";
  exec.start    += "/sbin/ifconfig ${epair}b ${ip} up";
  exec.start    += "/sbin/route add default ${gateway}";
  exec.poststop  = "/sbin/ifconfig ${bridge} deletem ${epair}a";
  exec.poststop += "/sbin/ifconfig ${epair}a destroy";
 
  exec.start    += "/bin/sh /etc/rc";

}

Then I have tried to launch the jail using:

service jail onestart freebsd5

but I get the following error message, I guess because FreeBSD5 does not support bridges.

Code:
Starting jails: cannot start jail  "freebsd5": 
ifconfig: interface epair29 already exists
jail: freebsd5: /sbin/ifconfig epair29 create up: failed
.

What would be the equivalent way to configure this taking into consideration such ancient/legacy release?
Would there be any more caveats to support FreeBSD5 in a Jail in FreeBSD14?
 
If I recall correctly 5 didn't have VNET jails yet. You might be able to get it to work with a 'standard' jail.
 
If I recall correctly 5 didn't have VNET jails yet. You might be able to get it to work with a 'standard' jail.
thanks,

Any further elaboratation on how a “standard” configuration might look like would be welcomed. Networking in jails is sometimes challenging.
 

Just to be sure that I understand the differences between this and VNET, it is my understanding that:

1. this implies that all services in the host (the server containing the jails) need to be explicitly configured/bind to the specific IP of the host to avoid the host hijacking the services from the jails
2. the jails no longer have their own network stack (no routing/pf per jail, which is not necessarily a bad thing)
3. the jails do not receive/view traffic addressed to host IP or other jail’s IPs

Thanks in advance for comments if I am missing any other difference or the above is not accurate.

Postscript: “Mastering Jails” booklet seems to be very useful resource to understand jails.
 
Inheriting the host network stack might help, which means not using VNET:

sh:
# appjail fetch empty -a amd64 -v 5.5-RELEASE
/cloud-machine/appjail/releases/amd64/5.5-RELEASE/default
# mkdir -p tmp
# cd ./tmp/
# for s in aa ab ac ad ae af ag ah ai aj ak al am an ao ap aq ar as at au av aw ax ay az ba bb bc bd be bf bg bh bi bj; do
fetch http://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/amd64/5.5-RELEASE/base/base.$s
done
# cat base.?? | tar -C /cloud-machine/appjail/releases/amd64/5.5-RELEASE/default/release -xf -
# cp /usr/local/share/appjail/files/default_template.conf template.conf
# chmod +w template.conf
# appjail-config set -t template.conf allow.raw_sockets
# appjail quick jlegacy start overwrite=force alias ip4_inherit osversion=5.5-RELEASE type=thick template=$PWD/template.conf
...
# appjail cmd jexec jlegacy ping -c4 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: icmp_seq=0 ttl=54 time=93.088 ms
64 bytes from 1.1.1.1: icmp_seq=1 ttl=54 time=91.561 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=54 time=91.766 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=54 time=91.929 ms

--- 1.1.1.1 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 91.561/92.086/93.088/0.593 ms
 
Networking works, but after installing I can't login remotely other than via jexec login.


$ ssh -oHostKeyAlgorithms=+ssh-dss -oKexAlgorithms=+diffie-hellman-group1-sha1 192.168.1.29
...
PTY allocation request failed on channel 0



$ telnet 192.168.1.29
Trying 192.168.1.29...
Connected to 192.168.1.29.
Escape character is '^]'.
telnetd: All network ports in use.

Connection closed by foreign host.

My best guess is that the device files for the pty's are missing. This is the contents of /dev in the jail


$ ls /dev
fd null pts random stderr stdin stdout urandom zero
 
Networking works, but after installing I can't login remotely other than via jexec login.


$ ssh -oHostKeyAlgorithms=+ssh-dss -oKexAlgorithms=+diffie-hellman-group1-sha1 192.168.1.29
...
PTY allocation request failed on channel 0



$ telnet 192.168.1.29
Trying 192.168.1.29...
Connected to 192.168.1.29.
Escape character is '^]'.
telnetd: All network ports in use.

Connection closed by foreign host.

My best guess is that the device files for the pty's are missing. This is the contents of /dev in the jail


$ ls /dev
fd null pts random stderr stdin stdout urandom zero
It is preferable to log into the host rather than the jail, fewer services to start and configure, and probably the SSH server running inside the jail has some vulnerabilities to exploit. But if you do it for fun and education, take a look at devfs.rules(5) to unhide the device needed for ssh to work inside the jail. Of course, you need to specify the rule set in your jail.conf(5).
 
Back
Top