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.