Bug 1096830

Setting devel_ack back to '?' as I did not understand the original description...  Are you saying you just copied the timezone file over to /etc/localtime?  How do you expect me to derive the original timezone info from that?

If someone wants to do this, they will just need to create a file called  "/etc/sysconfig/regdomain" with a "COUNTRY=" line in it.

Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

(In reply to John W. Linville from comment #1)
> Are you saying you just copied the timezone file over to /etc/localtime?

yes

> How do you expect me to derive the original timezone info from that?

I don't know :-)

so I read this as an official statement that it is not supported this way; I'll modify the test to expect failure in this scenario

but in that case, please let me reopen and make it docs bug

I'd suggest extending the man page, something like this:


NAME
       setregdomain - set regulatory domain based on country or timezone information

SYNOPSIS
       setregdomain

DESCRIPTION
       setregdomain sets the regulatory domain for your system; it takes no arguments and is normally called via system script (eg, udev) rather than manually by an adminstrator.
       The regulatory domain is set as ISO / IEC 3166 alpha2 country code value to 'COUNTRY' variable defined in /etc/sysconfig/regdomain. If that is unavailable, setregdomain falls back to determining country information from system time zone. For this to work, /etc/localtime has to be a symlink to a tzfile under /usr/share/zoneinfo/ associated to a country via zone.tab file.

FILES
       /etc/sysconfig/regdomain
       /etc/localtime

SEE ALSO
       iw(1)

and while at it, the error message

"Timezone information not set!  Unable to set regulatory domain."

is misleading in this case, the zone is set but cannot be used, I'd suggest

"Could not determine time zone!  Unable to set regulatory domain."

and there should be nonzero exit code

now I've noticed a typo ...

adminstrator => administrator

What (if any) objections do you have to the following man page text?

segregdomain(1)                  User Commands                 segregdomain(1)



NAME
       setregdomain - set regulatory domain based on country code

SYNOPSIS
       setregdomain

DESCRIPTION
       setregdomain  sets  the  regulatory domain for your system; it takes no
       arguments and is normally called via system script  (eg,  udev)  rather
       than manually by an administrator.

       The  regulatory  domain  is  represented  by an ISO / IEC 3166-1 alpha2
       country code.  By  default,  setregdomain  attempts  to  determine  the
       appropriate  country code by examining the target of the /etc/localtime
       symbolic link.  That information is used to look-up the matching  coun‐
       try code in the /usr/share/zoneinfo/zone.tab file. 

       The  country  code  lookup  may  fail.   This could be due to faulty or
       incomplete information in the /usr/share/zoneinfo/zone.tab file, or the
       use  of an actual file rather than a symlink for /etc/localtime , among 
       other possibilities.  In those cases the  system  administrator  should
       define  a  COUNTRY environment variable in the /etc/sysconfig/regdomain
       file.  This value will be used as the country code and the country code
       look-up will be skipped.

FILES
       /etc/sysconfig/regdomain /etc/localtime /usr/share/zoneinfo/zone.tab

SEE ALSO 
       iw(1)



CRDA                              2014-11-19                   segregdomain(1)

John, the text looks sane for me but I am missing description of exit codes.

(In reply to John W. Linville from comment #7)
> What (if any) objections do you have to the following man page text?

looks good to me (better than #c4, FTR), thanks

I've asked colleagues for independent review (as I already know the sources ...), so there's some more feedback ^ (#c8)

*** Bug 1166718 has been marked as a duplicate of this bug. ***

Verified that the new manpage test matches that provided in comment 7. Tested using RHEL-7.2-20150612.n.1.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2186.html