t;,
which is a tool for downloading packages (including source RPMs) without
actually installing them.
--
Daniel Maher
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
rnel.org/pub/linux/libs/pam/Linux-PAM-html/sag-pam_listfile.html
--
Daniel Maher
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
s. Angel Bosch Mora - turns out you may have been right the first
time ! :) ).
--
Daniel Maher
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
e following way :
ldapA 10.0.0.2
As you can see, there is only one relevant hostname, therefore there are
no other additional hostnames to generate a certificate for.
--
Daniel Maher
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
the slave be able to
respond to incoming SSL requests with exactly the same credentials as
the master. Is this even possible, and if so, how would i got about
doing it ?
Thank you, all.
--
Daniel Maher
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
terested in other solutions that may be out there.
>
> Thanks!
>
We've been using « LAM » (LDAP Account Manager) for a while now. It's
simple, but it works, and it handles both Posix and Samba concerns quite
nicely.
http://www.ldap-account-manager.org/
--
Daniel Maher
ct that solutions to this problem probably falls outside of what can
> be configured in 389?
While it's not a 389-specific suggestion, iptables could easily solve
this problem for you across the board. :)
--
Daniel Maher
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
fail item=group sense=allow
file=/etc/ssh_login_groups
I then created an LDAP group called "disabled", and now instead of
deactivating users in the traditional sense, i simply revoke their group
membership and put them into the disabled group. Since that group isn't
listed in the l
"cn" means "Common Name", and it generally contains a
person's name. Based on what you've described above, there is no IT group.
The Apache error contains the string "/secure", but the LDAP search
string you provided does not. You might want to verify that.
--
Daniel Maher
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
ed many options but its not working.
> Please help.
Please provide more details, for example, the OUs and DNs (sanitised if
necessary), the search string (or equivalent) that you're using to
authenticate, and any other relavant information (environment, etc..).
--
Daniel
reshark (gnome) via ssh -X to
the remote site, and from the same machine that i would normally have
run 389-console from. It was relatively responsive - certainly usable,
in any case.
Could it be a java thing, or is it specific to the console tool, i wonder ?
--
Daniel Maher
--
389 users
uot;...
Could you provide any further details about the state of the network(s)
between your local and remote sites ? VPN ?
--
Daniel Maher
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
t; I'm not sure if this is caused by the application problem or this is
> expected RHEL behaviour?
Which RHEL ? Which architecture ? What sort of VM environment ?
I've ben running test case of 389 1.2.5 on CentOS 5.5 x86_64 (host &
guest) in a VirtualBox, and i've had no probl
nfiguration of the
>> plugin, or a bug with the plugin itself. Has anybody else experienced
>> similar behaviour?
> What platform? What is your 389-ds-base version?
Platform is addressed above already.
[r...@test-dma-36 ~]# rpm -qa | grep 389-ds-base
389-ds-base-1.
), so at least that
works. :)
Any help, or a push in the correct direction, would be greatly
appreciated. Thank you, all.
--
Daniel Maher
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
r occurs (unsurprisingly) for users added via the console
as well.
Reference :
CentOS 5.4 x86_64
389-ds via EPEL (vendorVersion: 389-Directory/1.2.5 B2010.012.2034)
--
Daniel Maher
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
here are no values, clicking «
OK » generates an error message, and thus the entry is never created.
If you add values, then DNA is irrelevant since you've manually entered
said numbers.
In other words, via the console, there is no way to have DNA generate
the uidNumber and gidNumb
On 04/14/2010 11:45 AM, Daniel Maher wrote:
> At ~ 09:28, i attempted to add the user entry as described above. At ~
> 09:29 i manually restarted the dirsrv service. As you can see, there
> are no long entries related to the interaction or the crash. The access
> log is silent on t
On 04/14/2010 11:45 AM, Daniel Maher wrote:
> When i use the console to add a new user, it expects there to be a value
> in three fields : UID Number, GID Number, and Home Directory. The
> console will not create the entry if those fields are empty. If i
This raises another question
19 matches
Mail list logo
