migrating vpopmail accounts to 389-directory server
by Levent ILDENIZ
Hi,
i want vpopmail accounts to transfer 389-directory server.
how can i do that
nice new years
--Levent
Bu mesaj ve onunla iletilen tum ekler gonderildigi kisi ya da kuruma ozel, gizlilik yukumlulugu tasiyor olabilir. Bu mesaj, hicbir sekilde, herhangi bir amac icin cogaltilamaz, yayinlanamaz ve para karsiligi satilamaz; mesajin yetkili alicisi veya alicisina iletmekten sorumlu kisi degilseniz, mesaj icerigini ya da eklerini kopyalamayiniz, yayinlamayiniz, baska kisilere yonlendirmeyiniz ve mesaji gonderen kisiyi derhal uyararak bu mesaji siliniz. Bu mesajin bilinen viruslere karsi kontrolleri yapilmistir.
ISTANBUL UNIVERSITESI
http://www.istanbul.edu.tr
This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary,privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product.If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and (i) destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication.
ISTANBUL UNIVERSITY
http://www.istanbul.edu.tr
14 years, 3 months
Re: [389-users] /etc/sudoers VS sudo-objects in directory server
by Morris, Patrick
On Tue, Dec 29, 2009 at 7:33 AM, Anne Cross <across itasoftware com>
wrote:
We're going to go with sudoers in ldap, not because I think it's
better, but because it's somewhat more secure. I think the layout
of how it's managed in ldap is much inferior (having to declare each
group multiple times, and not being able to apply privileges to a
*group*, is stupid) but it is at least someplace where I know the
clever people can't get easy access to it, and if the sudoers file
gets modified, I can have tripwire scream.
-- juniper
It's most definitely *not* the case that you cannot use groups in LDAP
sudoers objects. I'm also not sure why you'd need to declare groups
multiple times, or what "groups" means in this context, but it sounds
like you may just be doing things the hard way.
14 years, 3 months
389-directory and freeradius
by Levent ILDENIZ
Hi everyone,
389-directory is working with free-radius or it has any scheme for
freeradius
Bu mesaj ve onunla iletilen tum ekler gonderildigi kisi ya da kuruma ozel, gizlilik yukumlulugu tasiyor olabilir. Bu mesaj, hicbir sekilde, herhangi bir amac icin cogaltilamaz, yayinlanamaz ve para karsiligi satilamaz; mesajin yetkili alicisi veya alicisina iletmekten sorumlu kisi degilseniz, mesaj icerigini ya da eklerini kopyalamayiniz, yayinlamayiniz, baska kisilere yonlendirmeyiniz ve mesaji gonderen kisiyi derhal uyararak bu mesaji siliniz. Bu mesajin bilinen viruslere karsi kontrolleri yapilmistir.
ISTANBUL UNIVERSITESI
http://www.istanbul.edu.tr
This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary,privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product.If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and (i) destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication.
ISTANBUL UNIVERSITY
http://www.istanbul.edu.tr
14 years, 3 months
nscd: nss_ldap: could not search LDAP server - Server is unavailable
by Prashanth Sundaram
All,
I have two 389-ds servers with MMR via TLS and client hosts authenticating
via TLS. I see this error message in all client machines in
/var/log/messages. It seems nscd is failing at random intervals. Has anyone
seen this before?
Dec 29 10:35:35 dmc189 nscd: nss_ldap: could not search LDAP server - Server
is unavailable
Dec 29 11:00:21 dmc189 nscd: nss_ldap: could not search LDAP server - Server
is unavailable
Dec 29 11:12:15 dmc189 nscd: nss_ldap: could not search LDAP server - Server
is unavailable
Steps Taken:
1. start/stop/restart nscd.
2. ldapsearch works fine
3. Turned ON nscd.log (no useful info found)
4. URI in ldap.conf and CN on server-cer is same.
Possible causes:
In /etc/ldap.conf
:
nss_initgroups_ignoreusers
root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman
.
Is this config correct?
/etc/nscd.conf looks like this
logfile /var/log/nscd.log
# threads 6
# max-threads 128
server-user nscd
# stat-user nocpulse
debug-level 10
# reload-count 5
paranoia no
# restart-interval 3600
enable-cache passwd yes
positive-time-to-live passwd 600
negative-time-to-live passwd 20
suggested-size passwd 211
check-files passwd yes
persistent passwd yes
shared passwd yes
max-db-size passwd 33554432
auto-propagate passwd yes
enable-cache group yes
positive-time-to-live group 3600
negative-time-to-live group 60
suggested-size group 211
check-files group yes
persistent group yes
shared group yes
max-db-size group 33554432
auto-propagate group yes
enable-cache hosts yes
positive-time-to-live hosts 3600
negative-time-to-live hosts 20
suggested-size hosts 211
check-files hosts yes
persistent hosts yes
shared hosts yes
max-db-size hosts 33554432
14 years, 3 months
Is there a way to order search results
by Sean Brady
Hello,
Is there a way to have search results returned to the client in a particular order? The application that I am using to query 389 ds is Asterisk, and it has some limitations in the way that it handles the search results that are returned from the server. It seems that the order of search results changes depending on the attributes present on the object. I know that there is no way that it is 100% consistent, however the attribute order returned by searches seems to vary quite a bit.
Thanks for your help.
SB
14 years, 4 months
Cannot start Admin server - host_ip_init():
by Fairchild, Anthony
Hello,
I have installed 389 Directory Server (v 1.2.2) and Admin Server
(v1.1.8) on RHEL 5.4, and in the process of getting SSL/TLS configured I
have somehow gotten the administration server into a state where it will
not start. When I run the init script it fails, and the
/var/log/dirsrv/admin-serv/error file has the following entry:
[Wed Dec 23 10:15:32 2009] [crit] host_ip_init(): PSET failure: Could
not retrieve access hosts attribute (past error = ) Configuration failed
Googling the problem led me to
http://directory.fedoraproject.org/wiki/Howto:AdminServerLDAPMgmt -
which contains directions for modifying the nsAdminAccessAddresses and
nsAdminAccessHosts entries, which I did. The entries are currently as
follows:
nsAdminAccessAddresses: *
nsAdminAccessHosts:
Which from my reading of the documentation suggests that access is
unrestricted, but starting the server still fails. Does anybody out
there have a suggestion as to what it is I have broken?
--
Anthony
14 years, 4 months
389 AD password sync no longer works after upgrade from fds
by Jason Solan
Hello,
Recently we've upgraded our fds servers (1.1.3) to 389 (1.2.2). Doing
so seems to have broken password sync from 389 to Active Directory. All
other attributes are passing fine and passync from AD to 389 is working.
The AD machine has not been updated since before the upgrade of 389, at
which time the sync still worked.
No error occurs in the log, but the sync takes 10 minutes before timing
out and claiming success. After turning on more logging, the error log
reports:
"AD already has the current password for <CN>. Not sending password
modify to AD."
I brought this up on IRC the other day and got a response that this is
most likely bug:
https://bugzilla.redhat.com/show_bug.cgi?id=537956
(I think thats the bug, bugzilla is down for maintenance at the time of
this email)
Today I went and re-installed a new server and put fedora-ds on by
excluding the 389* packages. I imported my directory and enabled
windows sync on this system. The password sync works fine from this new
system.
Has anyone run into a similar issue?
Is there a way to downgrade after upgrading to 389?
Could the issue have anything to do with the name of the service (i.e.
changing a config parameter that windows sync uses from fedora-ds- to
389-)?
Could this still be the same bug as listed above, or should I open a new
one?
All fds/389 systems are centos 5.4
Packages on Working sync:
fedora-ds-console-1.2.0-1.fc6
fedora-ds-base-1.2.0-2.fc6
fedora-ds-dsgw-1.1.2-1.fc6
fedora-ds-admin-1.1.7-3.fc6
fedora-ds-1.1.3-1.fc6
fedora-ds-admin-console-1.1.3-1.fc6
Packages Non-working sync:
389-ds-console-1.2.0-4.el5
389-admin-1.1.8-4.el5
389-console-1.1.3-3.el5
389-ds-console-doc-1.2.0-4.el5
389-ds-1.1.3-4.el5
389-admin-console-1.1.4-1.el5
389-admin-console-doc-1.1.4-1.el5
389-adminutil-1.1.8-3.el5
389-ds-base-1.2.2-1.el5
389-dsgw-1.1.4-1.el5
IMPORTANT:
This transmission is sent on behalf of Knouse Foods ® for business
purposes. It is for the intended recipient only. If you are not the intended
recipient or a person responsible for delivering this transmission to
the intended recipient, you may not disclose, copy or distribute this
transmission or take any action in reliance on it. If you received this
transmission in error, please notify us immediately by replying to this
Email message, and please dispose of and delete this transmission.
Thank you.
14 years, 4 months
Re: [389-users] Announcing 389 Directory Server 1.2.5 Release Candidate 2
by Anne (juniper) Cross
I'm having problems installing via yum, even with an import of the gpg key at http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA7B02652 - are the packages in the testing directory signed with a different key?
"Package 389-ds-base-1.2.5-0.3.rc2.el5.x86_64.rpm is not signed"
-- juniper
----- Original Message -----
From: "Rich Megginson" <rmeggins(a)redhat.com>
To: 389-announce(a)redhat.com, 389-users(a)redhat.com
Sent: Monday, December 7, 2009 6:57:20 PM GMT -05:00 US/Canada Eastern
Subject: [389-users] Announcing 389 Directory Server 1.2.5 Release Candidate 2
The 389 team is pleased to announce the availability of Release
Candidate 2 of version 1.2.5.
We need your help! Please help us test this software. It is a Release
Candidate, so it is fairly stable at this point. We have worked hard to
make sure upgrades from previous releases are as smooth as possible, and
we would really appreciate feedback about upgrades. The Fedora system
strongly encourages packages to be in Testing until verified and pushed
to Stable. If we don't get any feedback while the packages are in
Testing, the packages will remain in limbo, or get pushed to Stable.
The more testing we get, the faster we can release these packages to Stable.
* Release Notes - http://directory.fedoraproject.org/wiki/Release_Notes
* Install_Guide - http://directory.fedoraproject.org/wiki/Install_Guide
* Download - http://directory.fedoraproject.org/wiki/Download
=== New features ===
None - this release is primarily to fix some bugs found in 1.2.5.rc1,
including a bug that causes import to crash when reading the
userPassword attribute.
=== Bugs Fixed ===
This release contains a couple of bug fixes. The complete list of bugs
fixed is found at the link below. Note that bugs marked as MODIFIED
have been fixed but are still in testing.
* Tracking bug for 1.2.5 release -
[https://bugzilla.redhat.com/showdependencytree.cgi?id=533025&hide_resolved=0
https://bugzilla.redhat.com/showdependencytree.cgi?id=533025&hide_resolved=0]
* [https://bugzilla.redhat.com/show_bug.cgi?id=195302 195302] local pwp
can't set storage scheme
* [https://bugzilla.redhat.com/show_bug.cgi?id=387681 387681]
"windows_process_dirsync_entry: failed to map tombstone dn." with , in
DisplayName
* [https://bugzilla.redhat.com/show_bug.cgi?id=486171 486171] [RFE]
Access log - Failed binds
* [https://bugzilla.redhat.com/show_bug.cgi?id=497199 497199] 'failed to
send dirsync search request 2' error
* [https://bugzilla.redhat.com/show_bug.cgi?id=504817 504817] [Double
quoted distinguished names not working in fedora-ds 1.2.0
* [https://bugzilla.redhat.com/show_bug.cgi?id=515329 515329] Multiple
mods in one operation can result in an inconsistent replica
* [https://bugzilla.redhat.com/show_bug.cgi?id=540559 540559] selinux
policy needs to allow log pipe [See dependency tree for bug 540559]
--
389 users mailing list
389-users(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-users
14 years, 4 months
memberOf task problem
by John A. Sullivan III
Hello, all. We are in the process of upgrading from 8.0 to 8.1. We've
hit a few glitches along the way but most has gone well. However, we
wanted to implement the new memberOf functionality. We successfully
added the plugin by editing dse.ldif and enabled it from the console.
However, we've been unsuccessful in having existing group membership
assigned to the memberOf attribute.
We first tried to run fixup-memberOf.pl but the script does not exist.
There is a template.fixup-memberOf.pl but this does not seem to have
been built into a final script.
We then thought we would use the new task feature of the console. We
went to cn=memberof task,cn=tasks,cn=config and tried to create the task
object. There was no nsDirectoryServerTask objectclass. We added an
nstask but then found there was no basedn attribute we could add. We
then created an extensibleobject instead but still not basedn attribute.
Finally, we resorted to ldapmodify (we hesitated just because we are not
very familiar with the command line tools). First, we did:
dn: cn=fixMemberOf,cn=memberof task,cn=tasks,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
cn: fixMemberOf
basedn: o=Internal,dc=ssiservices,dc=biz
The Internal Organization has several organizations under it (for
various clients) and then user organizational units under those
organizations. Although it generated no errors, it did not seem to
work. Perhaps I just don't know how to test it. However, the following
did not return an memberOf data:
/usr/lib64/mozldap/ldapsearch -b
"ou=Users,o=client1,o=Internal,dc=ssiservices,dc=biz" -D "cn=Directory
Manager" -w - -h ldap uid=myid memberOf
Doing /usr/lib64/mozldap/ldapsearch -b
"ou=Users,o=client1,o=Internal,dc=ssiservices,dc=biz" -D "cn=Directory
Manager" -w - -h ldap uid=myid
showed me plenty of attributes but nothing for memberOf
I also tried creating the task with a basedn of
ou=Users,o=client1,o=Internal,dc=ssiservices,dc=biz in case it did not
change objects lower in the tree. Still no success.
Finally I tried:
dn: cn=fixMemberOf,cn=memberof task,cn=tasks,cn=config
changetype: add
objectclass: top
objectclass: nsDirectoryServerTask
cn: fixMemberOf
basedn: o=Internal,dc=ssiservices,dc=biz
adding new entry cn=fixMemberOf,cn=memberof task,cn=tasks,cn=config
ldap_add: Object class violation
ldap_add: additional info: unknown object class "nsDirectoryServerTask"
And received the expected unknown object class error.
What are we doing wrong? Are these documentation bugs? Are there
application bugs or do we simply not know what we are doing with tasks
and memberOf? How do we get the memberOf information into our existing
user objects? Thanks - John
--
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan(a)opensourcedevel.com
http://www.spiritualoutreach.com
Making Christianity intelligible to secular society
14 years, 4 months
