[OpenAFS] asetkey and bos_setcellname in 1.8.3

[Michael Meffie]

Hello,

Yes, asetkey and akeyconvert require the server side cell configuration
directory and files (ThisCell and CellServDB) in the current implementation.
I do not think this is new with 1.8.x, but in 1.6.x (after 1.6.5), asetkey
was not required, since the servers used the rxkad.keytab files directly.

The current procedure is to create the cell configuration directory before
running asetkey. The default values of ThisCell and CellServDB works for
this, so those can be created by running the bosserver once to create
the default values of those files before running asetkey or akeyconvert,
or have something to create the files before starting the bosserver. (In
the old days, back when kaserver was still in use, the bosserver would
be started once in "-noauth" mode, which would create those directories
and files, but noauth is no longer needed for regular use, but asetkey
still needs the cell configuration files.)

I do not think asetkey/akeyconvert actually needs the values of the
ThisCell/CellServDB, it is just a consequence of the "auth" library
used by asetkey/akeyconvert as currently implemented, so this could
probably be improved and would make it easier to bring up a new cell.

Best regards,
Mike

On Mon, 5 Aug 2019 01:31:58 -0700
<xguan@reliancememory.com> wrote:

> There seems to be a causality dilemma between asetkey and bos_setcellname
> when a new cell is brought up, at least in 1.8.3. 
> 
>  
> 
> Invoking asetkey on a vanilla server (binary installation, 1st database
> server) leads to an error if it is before the initialization of krb.conf and
> ThisCell
> 
>  
> 
> $ asetkey add rxkad_krb5 4 18  <keyfile> <princ>
> 
> asetkey: can't initialize conf dir '/etc/openafs/server'
> 
>  
> 
> Looking at the source code of asetkey.c, the first thing main() does is to
> check if confdir is valid:
> 
>  
> 
> tdir = afsconf_Open(confdir);
> 
>     if (!tdir) {
> 
>               fprintf(stderr, "%s: can't initialize conf dir '%s'\n",
> argv[0],
> 
>                            confdir);
> 
>               exit(1);
> 
>     }
> 
>  
> 
> https://github.com/openafs/openafs/blob/85d70ea953c6fb44f200ed4be13cded74135
> 59b8/src/aklog/asetkey.c#L448
> 
>  
> 
> With trial and error, it seems that afsconf_Open() won't succeed unless
> ThisCell and krb.conf are both properly configured. 
> 
>  
> 
> While krb.conf can be configured manually, ThisCell has NOT been initialized
> at this step. It is yet to be filled by "bos setcellname -localauth", which
> requires the key to be in place and the bosserver to be running in the
> background. So it seems to be a chicken or the egg problem. 
> 
>  
> 
> bos_setcellname requires a bosserver daemon launched. Launching bosserver
> without an initialized confdir always fails on my case. I suspect the
> following section of bosserver.c is responsible
> 
>  
> 
> tdir = afsconf_Open(AFSDIR_SERVER_ETC_DIRPATH);
> 
>     if (!tdir) {
> 
>               tdir = CreateLocalCellConfig();
> 
> }
> 
>  
> 
> which fails because CreateLocalCellConfig() calls afsconf_SetCellInfo() with
> a __NULL__ in its first argument. bosserver then exits abnormally. 
> 
>  
> 
> Step-to-step guidance for newcomers usually instructs a user to key the
> server before bos_setcellname. For example:
> 
> https://wiki.openafs.org/admin/InstallingOpenAFSonCentOS7/
> 
> https://wiki.gentoo.org/wiki/OpenAFS#Keying_the_Server
> 
>  
> 
> To break the chain, I manually configured krb.conf and ThisCell, then
> invoked asetkey. After successful keying, bosserver can be launched and
> bos_setcellname can be invoked with "-localauth"
> 
>  
> 
> 1.6.2x was largely exempted from that problem if a user uses rxkad.keytab
> instead of invoking "asetkey". But in 1.8 we see the return of asetkey for
> Kerberos 5. 
> 
>  
> 
> Can OpenAFS gurus confirm the issue? I think it will make life much easier
> for new users to bring up a cell.
> 
>  
> 
> Thanks.
> 
>  
> 
> ==========================
> 
> Ximeng (Simon) Guan, Ph.D.
> 
> Director of Device Technology
> 
> Reliance Memory
> 
> ==========================
> 
>  
> 


-- 
Michael Meffie <mmeffie@sinenomine.net>