-
Notifications
You must be signed in to change notification settings - Fork 145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support static MAC address + fix clone VNET jail #725
Conversation
This commit will generate a static MAC address for each jail, based on the name of the jail. It will use the first half (xx:xx:xx) of the host MAC to avoid network clashes, and generate a random HEX string from the hashed name of the jail. It will then add that random 5 character HEX string in MAC format, and add an "a" and "b" for the host and jail respectively. This way a jail can retain it's MAC ID even if it is deleted and reinstalled, as long as the same name is retained.
Current implementation allows for cloning jails that were created using a static MAC. Also removed some unnecessary sed strings. These were simplified.
- fixed cloning of VNET bridged jails - added support for regenerating static MAC on cloned jails - simplified some sed commands to edit cloned jail.conf file Tested with bridged VNET, VNET, and loopback jails
- support static MAC on bridged and VNET jails - remove quotes around vnet.interface
Bumping this to get some conversation going. Thoughts? |
This reverts some changes the the "update_jailconf" function. The reason behind this revert is that if a jail somehow has the same name as a directory, then the previous commit would have changed the directory name as well, which would break stuff. The current code avoids all that and only replaces the necessary jail name value.
I've reverted some edits to the The other parts seem fine though, regarding the static MAC and cloning jails, so I'm still pushing for this PR. |
I've modified this to include the function "generate_static_mac" in "common.sh" since it is only ever used when creating a jail. When cloning a jail, the same principle is used, but since the "external_interface" variable is not passed to "clone.sh" it is handled like this: since the jail.conf file is copied over from the old jail, and then edited, we can simply "cat" it to retrieve the MAC prefix. Then, the same hashing method is applied to retrieve the suffix based on the new jail name. I've tested the clone function quite extensively, even cloning jail into the double digit numbers just to make sure the sed commands properly replace values in "jail.conf" and "rc.conf" |
so this PR ONLY changes mac address for vnet jails and bridged jails, not others. @tschettervictor, correct? It does not make any changes to a shared networking, which uses the mac address of the adapter for the mac address, all the same. Did you intend it to touch shared networking devices? |
That is correct. Only VNET and bridged VNET are affected. Shared network jails do not need to have a static MAC or any type of MAC really, since they use the host stack. |
when I clone a vnet jail, it gets a new hwaddr. BUT if I reboot a cloned jail the hwaddr changes. It didn't on the original jail I cloned from, it was static. What am I missing? |
I'm not 100% sure what the hw address if for to be honest. But the actual MAC is the one found under "ether" Iocage does it the same way. |
PR tests OK for me. no issues I can find. @yaazkal is going to confirm my testing prior to merging this pr. |
same error. not cloning jail correctly. root@fbsd:/usr/local/share/bastille # bastille clone jail4 clonedjail4 192.168.1.238/24 |
grep: /usr/local/bastille/jails/clonedjail4/jail.conf: No such file or directory that is the error that is blowing it up. Mine is NOT copying the jail.conf file over, nor is it writing a new one. Looked at the code and did NOT see where it copies over or creates the new jail.conf file prior to checking for it. also, just checked and it is not even creating a directory for the new cloned jail at all. So no path for it to follow to find a conf file. |
from looking at the code, there is a copy command to copy the jail.conf when you are NOT using zfs, that is line 194. But looking above that in the zfs section I do not see it copying the jail.conf file over and creating the paths. I have zfs enabled on all my stuff. What am I missing in the section from line 167 to 185 where it should create the path and copy the jail.conf file over . |
ZFS clones the entire jail dataset and sends it to the new location, so the jail.conf file is included. Can you share the output of "mount | grep yournewjailname? |
One thing to not. I had to let bastille create its own "bastille_zfs_prefix" which it then mounts at "bastille_prefix" If this is not done, then it is not mounted at the right place, and bastille will not use "bastille_prefix" as its mount point. This results in jails not ending up where bastille expects them to end up. |
root@fbsd:/home/bmccormick # mount | grep jail4 |
I let bastille create all the mount points. I did exactly ONLY the steps I listed a few comments ago. |
jail4 is the one I am trying to clone. The NEW jail does not show any mount points nor does it create the directory for it at all
|
What does ZFS list show? I had one issue where it was trying to take snapshots when they were already created, and it errored out. Also, maybe add "set -x" to the clone file to see what's going on. |
root@fbsd:/home/bmccormick # zfs list |
Your bastille mounts aren't even showing... I'm on IRC now. How can we hook up? |
ZFS optionsbastille_zfs_enable="YES" ## default: "" all default options, no changes from default |
You have to add your zpool there. Here is my zfs list
|
zroot/bastille is mounted at /usr/local/bastille |
what is your bastille.conf ? |
ZFS optionsbastille_zfs_enable="YES" ## default: "" Everything else is default. |
ZFS optionsbastille_zfs_enable="YES" ## default: "" mine and it is not creating mount points like yours |
You need to let bastille create "zroot/bastille" or it will not mount it correctly. I recommend trashing it and restarting. Just zfs destroy -r zroot/bastille Then bootstrap a release and it will do its thing automatically. |
root@fbsd:/usr/local/etc/bastille # bastille list all jail6 and jail7 were created after setting the zfs root setting. Still no love |
I had to completely restart after that happened to me. The problem is that if bastille does not create the zroot/bastille dataset, then it never gets mounted at the right place. This then affects everything going forward. |
cannot create 'zroot/bastille/jails/jail7': parent does not exist |
Were you able to destroy zroot/bastille? I had that error too before I completely wiped it. |
the default settings are NOT to create a new zfs mount for each jail. The default action is to just put them in the |
root@fbsd:/home/bmccormick # bastille create -V jail8 14.1-RELEASE 192.168.1.162/24 re0 Creating a thinjail... no IP address found for not set |
after fixing my zfs issues this PR tests correctly. things tested.
Merging PR |
thank you @bmac2 unfortunately I had no time to test it. |
This PR adds some functionality, and some fixes.
This PR has been tested with bridged VNET, VNET, and loopback jails. Steps below