This is the most common problem with the export of data. The most modern Unix systems change the owner of local drives (if you can change the medias) to the UID and GID of the user who is logged in on the console. If you want to export something to the floppy then there are three choices:
The simplest solution is to change the permissions itself and to allow every other user to write on the disk.
chmod a+w /dev/fd0
If you run no X server or better no xdm (including gdm
and kdm etc.) then it makes sense to simply change the
group and perhaps the owner of the device. This
operation makes no sense if you run xdm because there
is a PAM module for device settings and this PAM module
is usually included into
/etc/pam.d/xdm
.
chown wwwuser:wwwowner /dev/fd0 chmod u+w /dev/fd0
If you run OpenCA on a production system and you run an xdm on this system then you should use this way of changing the permissions but be prepared this is not very easy and you must test the changes very carefully.
First you have to edit
/etc/logindevperm
. Please
comment out the line which defines the settings for
/dev/fd0
. This will avoid the
PAM module devperm from
changing the owner (UID) and group (GID) of the
device. Usually the PAM module is used by xdm
(see /etc/pam.d/xdm
) and other
console based services.
Now you can do the same like for the first or the second choice.
chown wwwuser:wwwowner /dev/fd0 chmod u+w /dev/fd0 or chmod a+w /dev/fd0
Now the change of the permissions is durable. The changes in the first and second choice are not durable if you use the PAM module devperm. Please don't wonder if a normal user cannot mount a floppy after these operations.
Do you see the following during the import:
Test the archive ... /bin/tar -tvf /dev/fd0 Importing archive ... Load required variables ... Changing to directory /usr/local/openca.0.9.1/openca/var/tmp/tmp_418 ... Running the import command(s) ... /bin/tar -xvf /dev/fd0 -C /usr/local/openca.0.9.1/openca/var/tmp/tmp_418 Importing the RBAC-configuration ... Ok. LDAP-support is activated Automatic LDAP-update is activated Importing _CA_CERTIFICATE ... No objects are present. Importing CA-Certificates into ldap ... Cannot load CA-certificate Make CA-Certificate available on the server ...OK. Re-Building CA Chain ... Ok. Clean up ...Ok.
The important thing is the line:
Importing _CA_CERTIFICATE ...
If you see this line then your configuration for the
dataexchange is wrong. This can happen if you installed the
online components with
--with-hierarchy-level
=ca
.
A CA doesn't import of course a CA certificate.
You can check the option
DOWNLOAD_CA_CERTIFICATE_STATES
in your
configuration files. It should contain at minimum
VALID
.
Go to OPENCADIR/var/log/enroll
and
OPENCADIR/var/log/download
. There you
have to remove all data from files which contain the module ID
of the node interface on the online server which crashed. If you
run the import/export commands next time then all objects will
be exported again. It is the same technology like for the
creation of a new node interface.
Usually the log from the export shows no requests or looks like this:
Example E.21. Failed request upload
Exporting _REQUEST ... FAILURE: 288 (spkac). FILE: /srv/ra//OpenCA/var/tmp/tmp_1517/_REQUEST//288.spkac FAILURE: 544 (spkac). FILE: /srv/ra//OpenCA/var/tmp/tmp_1517/_REQUEST//544.spkac Exporting archive ...
The symptom is “Exporting _REQUEST”. This shows that there are no status specified for the export of requests. New version of OpenCA simply ignore the requests and show nothing.
You can manually change the status of the requests which
should be uploaded or you install again. In the most cases there
was a wrong paramter for configure. Please check the value of
--with-hierarchy-level
very carefully. If you
install a RA and you want to export approved requests to the CA
then the hierarchy level must be ra
.