I would like to hear more opinions from others about the solution b)
which seems to be ok for me.
>>>>> On Sat, 19 May 2018 15:38:52 -0700, Derek Poon <derekp+...@ece.ubc.ca>
>>>>> said:
> Thomas,
> I'd like to revisit the issue of APT keys that I had mentioned earlier.
> FAI 5.5.3 changed the task_repository() function in
/usr/lib/fai/subroutines, such that it copies *.asc files into the target OS's
/etc/apt/
> trusted.gpg.d instead of calling `apt-key add`.
> This broke APT keys for target OSes that have apt < 1.4~beta1, which only
look for /etc/apt/trusted.gpg.d/*.gpg files. Since 1.4~beta1, APT will
> also look for /etc/apt/trusted.gpg.d/*.asc.
> FAI 5.6.1 introduces a workaround: for each relevant class, it copies a
$class.gpg file if it exists, and falls back to copying a $class.asc file.
> However, the FAI 5.6.1 behaviour still imposes an unreasonable burden of
maintaining redundant files in the package_config directory: .asc files
> for FAI clients older than 5.5.3, and .gpg files for FAI clients since
5.6.1.
> To summarize, FAI has traditionally supported ASCII-armored .asc key
files, and APT has traditionally supported dearmored .gpg key files. I
> see two possible good solutions:
> (a) Revert to the pre-5.5.3 behaviour, and call `apt-key add`. A
disadvantage is that it requires a working apt-key command in the target OS,
which
> may require the gnupg package to be installed (by debootstrap).
Unfortunately, it is neither easy nor desirable for FAI to demand that gnupg be
> installed in the target OS.
> (b) Run gpg in FAI to convert .asc files to .gpg files. This requires
the gnupg package to be installed in the NFS root (or wherever FAI is
> running from). We can ensure that the gpg command is available by
declaring that the fai-client package depends on (or recommends) gnupg, and by
> adding the gnupg package to the sample NFSROOT configuration.
> The following excerpt from /usr/lib/fai/subroutines implements option (b).
> # add apt keys for all classes
> for keyfile in ${classes:-}; do
> [ ! -f $FAI/package_config/$keyfile.asc ] && continue
> echo -n "Copying APT key from $keyfile.asc to $keyfile.asc.gpg "
> [ -f $FAI_ROOT/etc/apt/trusted.gpg.d/$keyfile.asc.gpg ] || touch
$FAI_ROOT/etc/apt/trusted.gpg.d/$keyfile.asc.gpg
> gpg --batch -o $FAI_ROOT/etc/apt/trusted.gpg.d/$keyfile.asc.gpg
--dearmor $FAI/package_config/$keyfile.asc
> done
> I hope that you will incorporate it, since this solution offers maximum
compatibility without introducing .gpg files into the package_config
> directory and without requiring that gnupg be installed into the target
OS. (It has the disadvantage of making assumptions about how apt-key
> interacts internally with its key files, but you already started down
that path by removing the apt-key call in 5.5.3.)
> Derek
> On May 18, 2018, at 1:13 PM, Derek Poon <derekp+...@ece.ubc.ca> wrote:
> In my experience, I have found two potential issues when installing
Ubuntu 18.04 using FAI.
> The first is that if using FAI <= 5.5, then FAI_DEBOOTSTRAP_OPTS
needs '--include gnupg'. Otherwise, the `apt-key add` in /usr/lib/fai/
> subroutines would fail. (At our site, we always run deboostrap
instead of relying on basefiles, and we often need backwards compatibility for
> dirinstalls.)
> The second is that netplan (see https://netplan.io/examples) is the
new preferred configuration format for networking [...]
> On May 18, 2018, at 11:04, Thomas Lange
<la...@informatik.uni-koeln.de> wrote:
> After building the basefile for Ubuntu 18.04 LTS aka Bionic, my
first
> tests look fine. Setting the release name in class/UBUNTU.var to
> ubuntudist=bionic
> and copying the basefile from
> https://fai-project.org/download/basefiles/BIONIC64.tar.xz
> works. Oh, I didn't test yet if the network is running after the
> installation. I will do this later.
--
regards Thomas
