When trying to start a jail with a dash in it, /etc/rc.d/jail loops printing the following message: /etc/rc.d/jail: WARNING: jail_extract_address: type not identified expr: illegal option -- b expr: usage: expr [-e] expression
Note: the name does not even have to be declared in jail.conf for this to trigger. Also the warning is dependend on the name given. E.g. # /etc/rc.d/jail start foo-bar /etc/rc.d/jail: WARNING: jail_extract_address: type not identified expr: illegal option -- b expr: usage: expr [-e] expression # /etc/rc.d/jail start bar-foo /etc/rc.d/jail: WARNING: jail_extract_address: type not identified expr: illegal option -- f expr: usage: expr [-e] expression
over to maintainers.
Can you provide more detail, like your jail.conf etc
The message occurs even without an existing /etc/jail.conf. The system is 10.0-RELEASE-p2 #1 r265140. What further information is required?
Created attachment 153050 [details] jail.conf Current jail.conf
I experience the same problem, I attached jail.conf in case that will help. I can start jails using jail -c dom-ldap01, but I cannot use service jail start or have them start at boot.
Comment on attachment 153050 [details] jail.conf Just use double quotes around the jail name ("dom-ldap01" { … }).
Created attachment 153948 [details] Safely map between jail names and rc.conf shell variables Currently, rc.d/jail will strip some special characters ('.' and '/') from a jail name, and replace them with underscores. That's sufficient for some purposes, but the requirements for shell variables are much stricter: only alphanumeric plus underscore. I don't want to restrict jail names that far, so I've split the jail name into two purposes. There's the jail's name which is as specified (e.g. on the command line) except with the '.' and '/' stripped out, and then the tag associated with jail variables which has all other non-alphanumeric characters also replaced with an underscore. These are in the variables $_j and $_jv throughout the script. If you have a jail named foo-bar, that's the name of the jail that would be created. It would have a conf file in /var/run/jail.foo-bar.conf, and store its id in /var/run/jail_foo-bar.id. If for some reason you wanted to continue to use old rc-shell-based configuration, the parameters would be along the lines of jail_foo_bar_ip and jail_foo_bar_hostname. Even if you use a proper jail.conf, the shell script won't get confused by illegal variable names.
A commit references this bug: Author: jamie Date: Sat Dec 26 23:01:35 UTC 2015 New revision: 292759 URL: https://svnweb.freebsd.org/changeset/base/292759 Log: Let old-style (shell-based) jail configuration handle jail names that contain characters not allowed in a shell variable (such as "-"). These will be replaced by an underscore in jail config variables, e.g. for jail "foo-bar" you would set "jail_foo_bar_hostname". This is separate from the current code that changes the jail names if they contain "." or "/". It also doesn't apply to jails defined in a jail.conf file. PR: 191181 MFC after: 5 days Changes: head/etc/rc.d/jail
A commit references this bug: Author: jamie Date: Thu Dec 31 01:24:16 UTC 2015 New revision: 292967 URL: https://svnweb.freebsd.org/changeset/base/292967 Log: MFC r292759: Let old-style (shell-based) jail configuration handle jail names that contain characters not allowed in a shell variable (such as "-"). These will be replaced by an underscore in jail config variables, e.g. for jail "foo-bar" you would set "jail_foo_bar_hostname". This is separate from the current code that changes the jail names if they contain "." or "/". It also doesn't apply to jails defined in a jail.conf file. PR: 191181 Changes: _U stable/10/ stable/10/etc/rc.d/jail
This has NOT been fixed, at least on 10.2-RELEASE-p10. # /etc/rc.d/jail start foo-bar /etc/rc.d/jail: WARNING: jail_extract_address: type not identified expr: illegal option -- b expr: usage: expr [-e] expression [endless loop] Please note that this even occurs with an empty jail.conf. with kind regards, Robert Schulze
No, it is not fixed in 10.2-RELEASE-p10. This is not the level of bug fix that will be going into errata and patching an existing release. It is fixed in CURRENT and in 10.0-STABLE, and will end up in 10.3.