10:09 a.m.
hi,
I noticed this entry when trying to use the db2bak.pl script.
I found out that the -a option only works when for example
the /var/lib/dirsrv/slapd-server/bak or a subdir is used (effectively)
the same dir as without the -a option.
I was using a root dir, which I also modded with nobody:nobody as
owner en chmod 777, but still no result.
Is this a bug, or does the server somehow checks the dir?
The backup script for an old iPlanet server does it too and is able to
use /local/bla without a problem.
Seems like a bug to me?
Greatings
Vincent
10:48 a.m.
New subject: Backup Directory Server by db2bak.pl script
On 05/13/2013 09:09 AM, Vincent Gerris wrote:
hi,
I noticed this entry when trying to use the db2bak.pl script.
I found out that the -a option only works when for example
the /var/lib/dirsrv/slapd-server/bak or a subdir is used (effectively)
the same dir as without the -a option.
I was using a root dir, which I also modded with nobody:nobody as
owner en chmod 777, but still no result.
Is this a bug, or does the server somehow checks the dir?
By default we protect certain directories with SELinux. What platform?
What version of 389-ds-base?
The backup script for an old iPlanet server does it too and is able
to
use /local/bla without a problem.
Seems like a bug to me?
Greatings
Vincent
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
11:09 a.m.
New subject: Backup Directory Server by db2bak.pl script
Hi Rich,
Thank you for the quick reply.
Great tip, selinux is indeed enabled.
We currently run Red Hat Directory Server 9.0 on Red Hat Enterprise
Linux 6 64 bit.
This is what selinux suggests (/var/log/messages):
Do
# semanage fcontext -a -t FILE_TYPE '/backup_cds'
where FILE_TYPE is one of the following: var_lock_t, tmp_t, tmpfs_t,
dirsrv_config_t, dirsrv_tmp_t, dirsrv_tmpfs_t, dirsrv_var_lock_t,
var_lib_t, var_run_t, var_log_t, dirsrv_var_log_t, dirsrv_var_lib_t,
dirsrv_var_run_t, pcscd_var_run_t, tmp_t, root_t, krb5_host_rcache_t.
Then execute:
restorecon -v '/backup_cds'
To fix it I used:
ls -l -Z /var/lib/dirsrv/slapd-examplesrv/bak
-rw-------. root root unconfined_u:object_r:dirsrv_var_lib_t:s0 dsbck1.tgz
So then :
chcon --reference /var/lib/dirsrv/slapd-examplesrv/bak /backup_cds/
and
restorecon -v '/backup_cds'
Then it worked!
Thank a lot!
Sorry for missing this, I hope it helps others too :).
Greetings Vincent
On Mon, May 13, 2013 at 5:48 PM, Rich Megginson <rmeggins(a)redhat.com> wrote:
On 05/13/2013 09:09 AM, Vincent Gerris wrote:
>
> hi,
>
> I noticed this entry when trying to use the db2bak.pl script.
> I found out that the -a option only works when for example
> the /var/lib/dirsrv/slapd-server/bak or a subdir is used (effectively)
> the same dir as without the -a option.
> I was using a root dir, which I also modded with nobody:nobody as
> owner en chmod 777, but still no result.
> Is this a bug, or does the server somehow checks the dir?
By default we protect certain directories with SELinux. What platform?
What version of 389-ds-base?
> The backup script for an old iPlanet server does it too and is able to
> use /local/bla without a problem.
> Seems like a bug to me?
>
> Greatings
> Vincent
> --
> 389 users mailing list
> 389-users(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
4008
days inactive
4008
days old
389-users@lists.fedoraproject.org
2 comments
2 participants
participants (2)
-
Rich Megginson -
Vincent Gerris