[Fedora-directory-users] Replication errors: Incremental Update Failed
I have four machines in an MMR setup. One recently died (got accidentally unplugged; d'oh!). When I started it back up, it recovered the database and then dumped errors like the following in the errors log: [04/Oct/2006:13:59:03 -0500] NSMMReplicationPlugin - agmt=cn=Replication to zeppo.nebrwesleyan.edu (zeppo:389): Missing data encountered [04/Oct/2006:13:59:04 -0500] NSMMReplicationPlugin - agmt=cn=Replication to zeppo.nebrwesleyan.edu (zeppo:389): Incremental update failed and requires administrator action The only info I found on this via Google was for Sun DS, and it just recommended updating to the latest hotfix. Obviously not terribly helpful. Anyhow have any ideas how I might fix this, short of re-initializing my directory on this machine? Thanks! I'm running: Name: fedora-dsRelocations: /opt/fedora-ds Version : 1.0.2 Vendor: (none) Release : 1.RHEL4 Build Date: Wed 01 Mar 2006 01:21:46 PM CST I used the mmr.pl script to set up replication, and it's been running fine for about 9 months now. Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Re: [Fedora-directory-users] Replication errors: Incremental Update Failed
On Wed, 4 Oct 2006, Richard Megginson wrote: There is a very small window of time between when the update is written to the main database and when it is written to the changelog database. If you kill the power during this window, the changelog db will be out of sync with the main database. The only solution is to reinit the server which has this problem. Thanks. Next question: what's the best (quickest, easiest) way to reinitialize the server? I can think of a few ways (e.g., reinstall), but can't shake the feeling that there must be a better way. Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Re: [Fedora-directory-users] Replication errors: Incremental Update Failed
On Thu, 5 Oct 2006, Richard Megginson wrote: Do you have another master? If so, just perform a replica initialization (using the console). We've got three other masters, but we don't use the console -- or have X installed or heads on the machines. Can this be done from the CLI, maybe with mmr.pl? Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Re: [Fedora-directory-users] Replication errors: Incremental Update Failed
I went through and re-init both of the databases on the problem machine, but still get the same errors. Also, if I restart FDS on the box, it claims to have been shutdown in a disorderly manner, even when I use stop-slapd. There are no errors related to the shutdown. It sounds like the BDB backend is pretty hosed, and even the auto recovery isn't completely handling it. Ideas? Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University On Thu, 5 Oct 2006, Richard Megginson wrote: Chris St. Pierre wrote: On Thu, 5 Oct 2006, Richard Megginson wrote: Do you have another master? If so, just perform a replica initialization (using the console). We've got three other masters, but we don't use the console -- or have X installed or heads on the machines. Can this be done from the CLI, maybe with mmr.pl? Not sure about mmr.pl, but yes, this can be done via ldapmodify. First, you have to find the DN of the replication agreement from another master to the one you want to initialize. ldapsearch -x -h othermaster -D cn=directory manager -w password -s sub -b cn=config objectclass=nsDS5ReplicationAgreement cn nsDS5ReplicaHost nsDS5ReplicaPort There may be several, you'll have to figure out which one goes to the master you want to initialize Next, use ldapmodify to start the repl init: ldapmodify -x -h othermaster -D cn=directory manager -w password dn: dn of the repl agreement changetype: modify replace: nsds5BeginReplicaRefresh nsds5BeginReplicaRefresh: start Then check the error logs for both masters to see when repl init is completed. Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
[Fedora-directory-users] fdsgraph: an rrdtool-based graphing utility for FDS
If any of you are familiar with mailgraph for Postfix-based mail servers, I've created something similar for Fedora DS. fdsgraph tails the access log and creates rrdtool-based graphs of the number of connections and operations, organized by connection security and op type respectively. You can see some screenshots and find the tarball at: http://www.nebrwesleyan.edu/people/stpierre/fdsgraph/fdsgraph.html Enjoy! Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Re: [Fedora-directory-users] Command-line Consumer Initialization
On Tue, 10 Oct 2006, Kimmo Koivisto wrote: Hello Mike I have used your mmr.pl script to deploy about 10 multimaster replicated FDS installations, it always worked fine. Those deployments have had two servers and I know that in near future I need to deploy four-way mmr. Your script's has the following options: --host1 FQDN of host 1 --host2 FQDN of host 2 --host1_idReplication ID number of host 1 --host2_idReplication ID number of host 2 When deploying four-way mmr, is it possible to define options --host3 and --host4 (and _id) options or how one should initialize four-way mmr? Best Regards Kimmo You'll want to set up two-way replication agreements between each pair of hosts in your setup. So if you had A, B, C, and D, you'd set up agreements between A-B, A-C, A-D, B-C, B-D, and C-D. Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Re: [Fedora-directory-users] usertools
On Wed, 11 Oct 2006, Gennaro Tortone wrote: Hi, I'm migrating our NIS authentication server to Fedora Directory Server; my problem is that all classic commands (useradd, userdel, chage, ...) don't work on users migrated on LDAP (FDS)... Is there something to configure ? (PAM, ...) I tried with pwdutils (http://www.thkukuk.de/pam/pwdutils/) but there are some authentication problems and the project seems to be not so active Any idea ? I think most people write their own scripts to create users, or do it through the console. However, I believe that many modern Linuxes will Do The Right Thing WRT the classic commands if you configure everything correctly. Try 'man ldap.conf'; I *think* that if you give it a bind password, etc., it'll try to add accounts. (It's quite possible that I'm totally and completely wrong about that.) There are two to three problems with that approach, though. First, it probably won't create the account the way you want it to, especially if you have anything beyond the most basic of environments. I've never used this before, but I doubt it'll add, e.g., Samba attributes. If you do anything beyond the bare minimum with POSIX attributes, it'll be insufficient. Second, /etc/ldap.conf has to be world-readable if you want other users to be able to run 'finger,' or even get proper results from 'ls' and 'stat'. If you specify your directory manager password in there, your directory has just been pwned. Thirdly, it assumes that you're running a recent Linux. For all I know, you could be on OS/2. :) So, while I think this might be possible, I'd recommend either using the console if you have a small number of accounts to create, or bust out the ol' Net::LDAP. Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Re: [Fedora-directory-users] fdsgraph: an rrdtool-based graphing utility for FDS
On Fri, 20 Oct 2006, [EMAIL PROTECTED] wrote: hmm perl-File-tail is not installed yet. but after i installed above packet, on browser doesn't appear any graph (only the header daily, weeky, so on) btw before i start the browser when starting the fdsgraph after installing perl-File-Tail, an error comes up [EMAIL PROTECTED] fdsgraph]# service fdsgraph start Starting fdsgraph fdsgraph: can't chdir to /var/lib/fdsgraph: No such file or directory at /usr/local/bin/fdsgraph.pl line 251. as an action i created the directory /var/lib/fdsgraph. then the service could runs but there is no graph appears am i missing some configuration? because i already follow the guide. thanks sigid Check the ownership on /var/lib/fdsgraph. It has to be readable by your web server. Also, check Apache's error logs; you should find error messages in there pointing you to what needs to be done. Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Re: [Fedora-directory-users] Can add with GUI, not with ldapmodify
What happens if you try to bind as the directory manager to create
Tony Tester's entry? I.e.,
ldapmodify -x -a -W -D cn=directory manager -h -f addtester.ldif
Chris St. Pierre
Unix Systems Administrator
Nebraska Wesleyan University
On Sat, 21 Oct 2006, Kyle Tucker wrote:
Hi,
New clean installation of Fedora DS 1.0.2 on FC5. I
added a first user with the admin console, exported it to see
its attributes and made a template to add a new user via LDIF
like below. If I try to add it with ldapmodify, I get this:
ldapmodify -x -a -W -D cn=Manager,dc=testdom,dc=net -h \
localhost -f addtester.ldif
Enter LDAP Password:
ldap_bind: No such object (32)
matched DN: dc=testdom,dc=net
If import the exact same LDIF file with the admin console, it
goes right in and all the attributes are fine.
Any ideas? Thanks.
dn: uid=tester, ou=People, dc=testdom,dc=net
changetype: add
objectClass: top
objectClass: person objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: posixAccount
ou: People cn: Tony Tester
sn: Tester
givenName: Tony
uid: tester telephoneNumber: 603-555-1212
loginShell: /bin/sh
gidNumber: 100
uidNumber: 503 mail: [EMAIL PROTECTED]
gecos: Tony Tester
homeDirectory: /usr/local/home/tester
userPassword: {SSHA}yYUVdAn95yDfzbIK92SuL0jK0cCnU//A
--
- Kyle
-
[EMAIL PROTECTED] http://www.panix.com/~kylet
-
--
Fedora-directory-users mailing list
Fedora-directory-users@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-users
--
Fedora-directory-users mailing list
Fedora-directory-users@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-users
Re: [Fedora-directory-users] Is it possible to use events to create homedirs when user entry is created or deleted?
On Fri, 27 Oct 2006, Kimmo Koivisto wrote: Does FDS have any event support that I could use or are there any existing solutions for this problem? There's a PAM module for this: pam_mkhomedir.so. You can configure it so that the first time someone logs in, their home dir is auto-created. We use that on the machines our users have shell access to, plus the root preexec directive for our Samba fileserver, to automatically generate home dirs. Just make sure that you have something in place to automatically delete them, too! :) Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Re: [Fedora-directory-users] Problems Setting up 1.0.3
Rich-- As I mentioned on IRC, I got about 90% of the way through the SSL setup before my deadline hit and I had to go live without SSL fully working. My machines are all listening on port 636, but don't do SSL properly. As far as I can tell/remember, I provisioned the boxes identically, so they all should be equally far along in the SSL-enabling process, but only one of them demonstrated the permissions problem. I guess you did say, though, that the problem _only_ happens to SSL-enabled machines, not that it _always_ happens to SSL-enabled machines. Still, hope this helps you root out the problem. Good luck! Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University On Thu, 2 Nov 2006, Richard Megginson wrote: It appears that the permission problem only happens with servers that were configured to use SSL in fds102 and upgraded to fds103. Can anyone confirm the problem occurred in a system not using SSL? -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Re: [Fedora-directory-users] Problems Setting up 1.0.3
After the update from 1.0.2 to 1.0.3, I had some replication problems, and it appears that one of my four servers was no longer properly replicating to the others. I recreated the replication agreements and reinitialized the replications, but now I'm getting some strange errors in the error logs of the borked server: [03/Nov/2006:08:54:23 -0600] NSMMReplicationPlugin - Total update aborted: Replication agreement for agmt=cn=Replication to zeppo.nebrwesleyan.edu (zeppo:389) can not be updated while the replica is disabled [03/Nov/2006:08:54:23 -0600] NSMMReplicationPlugin - (If the suffix is disabledyou must enable it then restart the server for replication to take place). This happens right after I try to re-init the replication agreements. I'm hoping that the fix is as simple as enabling the replication agreements; how do I do that (w/o console)? Also, it says I have to restart the server; which server? Consumer or producer? Thanks! Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Re: [Fedora-directory-users] Problems Setting up 1.0.3
On Fri, 3 Nov 2006, Richard Megginson wrote: The consumer. The supplier thinks the consumer suffix is disabled. It might be as simple a fix as restarting the consumer. That changed the error message. [03/Nov/2006:11:21:24 -0600] NSMMReplicationPlugin - agmt=cn=Replication to chico.nebrwesleyan.edu (chico:389): Replica has a different generation ID than the local data. I get that every 3-5 seconds WRT replication to the same host. When I restarted the problematic host, it reinitialized all of its replication agreements; do I need to reinitialize the agreement the other way, too? Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
[Fedora-directory-users] Announcing FDSGraph v0.2
I'm happy to announce the release of FDSGraph v0.2. The only major change is support for graphing TLS connections in addition to plaintext and SSL. FDSGraph also has a new home at LinuxLaboratory.org thanks to Brian K. Jones. Download: http://www.linuxlaboratory.org/?q=node/60 Original v0.1 announcement: http://www.mail-archive.com/fedora-directory-users@redhat.com/msg03832.html Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Re: [Fedora-directory-users] Announcing FDSGraph v0.2
The download link has been fixed. Oops. :) Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University On Mon, 8 Jan 2007, Chris St. Pierre wrote: I'm happy to announce the release of FDSGraph v0.2. The only major change is support for graphing TLS connections in addition to plaintext and SSL. FDSGraph also has a new home at LinuxLaboratory.org thanks to Brian K. Jones. Download: http://www.linuxlaboratory.org/?q=node/60 Original v0.1 announcement: http://www.mail-archive.com/fedora-directory-users@redhat.com/msg03832.html Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Re: [Fedora-directory-users] MMR broken, reinitialization erases db
On Thu, 22 Mar 2007, Richard Megginson wrote: You might try enabling the replication log level to see what is going on here. How do I do that? Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University Never send mail to [EMAIL PROTECTED] -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Re: [Fedora-directory-users] MMR broken, reinitialization erases db
On Thu, 22 Mar 2007, Chris St. Pierre wrote: I still have no clue what caused this initially, but I don't really care (unless it happens again). Predictably, it happened again. In fact, it happened as soon as I made the MMR cluster live again and operations started coming in. Here's the error message: [23/Mar/2007:09:59:02 -0500] - csngen_adjust_time: adjustment limit exceeded; value - 86401, limit - 86400 [23/Mar/2007:09:59:03 -0500] NSMMReplicationPlugin - conn=12 op=21 replica=o=isp: Unable to acquire replica: error: excessive clock skew The 'value' in the first line is always 86401. All four of our nodes have the same time; all use NTP against the same NTP server. All were patched for DST and subsequently rebooted. What the heck? Any ideas? Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University Never send mail to [EMAIL PROTECTED] -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Re: [Fedora-directory-users] rpm -e behavior
On Wed, 18 Jul 2007, Steve Rigler wrote: Personally, I prefer rpm -e to remove only the files that were originally installed by the package. I'll second that. Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University LOPSA Sysadmin Days: Professional Training for Professional SysAdmins August 6-7, Cherry Hill, NJ http://lopsa.org/SysadminDays -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Re: [Fedora-directory-users] rpm -e behavior
On Wed, 18 Jul 2007, Noriko Hosoi wrote: If rpm -e fedora-ds leaves all the directories listed above, the following rpm -i fedora-ds + setup operation would be the in-place upgrade instead of the fresh install if the same server ID (slapd-ID) is chosen. Maybe, that'd be the expected behavior for many administrators. For others, we could have one more question in the setup/upgrade dialog if the setup is a fresh install (wipe out the old files) or a in-place upgrade (use the old files). If the answer is fresh install, we can clean up the old files, then. Another thing is if the host is no longer used for the Fedora Directory Server, you may want to clean up the disk eventually. At that time, there is no tool to remove them. Theoretically, all the files/directories are under fedora-ds somewhere, so it won't be difficult to remove them manually, though. But it looks a little lame... If 'setup' creates all of that stuff, could there be an 'unsetup' command that removes it all? I.e., if installation is: rpm -hvU fedora-ds- /path/to/setup Then uninstallation could be: /path/to/unsetup rpm -e fedora-ds That way removal of all of the other stuff could be at the option of the administrator. Just a thought. I'm sure you have nothing better to do than write scripts consisting of a few hundred lines of rm. :) Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University LOPSA Sysadmin Days: Professional Training for Professional SysAdmins August 6-7, Cherry Hill, NJ http://lopsa.org/SysadminDays -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
[Fedora-directory-users] MMR broken, can't get it started again
I noticed today that replication between a few of my four FDS machines (all MMR agreements going every which way) had failed with errors like this: [30/Aug/2007:00:02:04 -0500] NSMMReplicationPlugin - agmt=cn=Replication to chico (o=isp) (chico:389): Incremental protocol: event update_window_opened should not occur in state start_backoff [31/Aug/2007:00:03:59 -0500] NSMMReplicationPlugin - agmt=cn=Replication to chico (o=isp) (chico:389): Incremental protocol: event update_window_opened should not occur in state start_backoff [31/Aug/2007:07:35:59 -0500] NSMMReplicationPlugin - agmt=cn=Replication to chico (o=isp) (chico:389): Incremental update failed and requires administrator action I tried using mmr.pl to reinitialize the agreements, but that failed miserably and wiped all of the data from the database I was re-initializing. I got the following errors on the supplier: [31/Aug/2007:10:24:56 -0500] NSMMReplicationPlugin - Beginning total update of replica agmt=cn=Replication to chico (o=isp) (chico:389). [31/Aug/2007:10:25:36 -0500] NSMMReplicationPlugin - agmt=cn=Replication to chico (o=isp) (chico:389): Failed to send extended operation: LDAP error 81 (Can't contact LDAP server) [31/Aug/2007:10:25:38 -0500] NSMMReplicationPlugin - agmt=cn=Replication to chico (o=isp) (chico:389): Received error 89: NULL for total update operation [31/Aug/2007:10:25:38 -0500] NSMMReplicationPlugin - agmt=cn=Replication to chico (o=isp) (chico:389): Received error 89: NULL for total update operation [31/Aug/2007:10:25:38 -0500] NSMMReplicationPlugin - agmt=cn=Replication to chico (o=isp) (chico:389): Received error 89: NULL for total update operation [31/Aug/2007:10:25:38 -0500] NSMMReplicationPlugin - agmt=cn=Replication to chico (o=isp) (chico:389): Received error 89: NULL for total update operation [31/Aug/2007:10:25:39 -0500] NSMMReplicationPlugin - agmt=cn=Replication to chico (o=isp) (chico:389): Received error 89: NULL for total update operation [31/Aug/2007:10:25:39 -0500] NSMMReplicationPlugin - agmt=cn=Replication to chico (o=isp) (chico:389): Warning: unable to send endReplication extended operation (Bad parameter to an ldap routine) And on the consumer: [31/Aug/2007:10:24:54 -0500] NSMMReplicationPlugin - multimaster_be_state_change: replica o=isp is going offline; disabling replication [31/Aug/2007:10:24:56 -0500] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [31/Aug/2007:10:25:16 -0500] - import userRoot: Processed 2036 entries -- average rate 101.8/sec, recent rate 101.8/sec, hit ratio 0% [31/Aug/2007:10:25:24 -0500] - ERROR bulk import abandoned [31/Aug/2007:10:25:24 -0500] - import userRoot: Aborting all import threads... [31/Aug/2007:10:25:31 -0500] - import userRoot: Import threads aborted. [31/Aug/2007:10:25:31 -0500] - import userRoot: Closing files... [31/Aug/2007:10:25:35 -0500] - libdb: userRoot/owner.db4: unable to flush: No such file or directory [...lots of lines like that...] [31/Aug/2007:10:25:36 -0500] - libdb: userRoot/id2entry.db4: unable to flush: No such file or directory [31/Aug/2007:10:25:36 -0500] - import userRoot: Import failed. [31/Aug/2007:10:25:36 -0500] - process_bulk_import_op: NULL backend At that point, the supplier crashes and we get the Can't contact LDAP server error in the consumer. This looked really similar to an error I'd had before, in this thread: http://www.mail-archive.com/fedora-directory-users@redhat.com/msg04969.html I had eventually resolved that by dismantling all replication information, using db2ldif to import the database from the supplier to the consumer while the consumer was down, bringing the consumer back up, and reinitializing the replication agreements. This has not worked this time; I get the exact same errors. Anyone have any suggestions? Thanks! Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
[Fedora-directory-users] Fedora DS in a Xen DomU?
I've been reading some things lately -- see, for instance, http://lists.xensource.com/archives/html/xen-users/2006-05/msg00853.html -- that suggests that running Fedora DS (or OpenLDAP, or, theoretically, any Berkeley-DB-reliant app) in a Xen DomU might not be the best idea. The thread mentioned above has a few people claiming it works fine for them, but both are at _very_ small sites. Can anyone either corroborate or debunk these claims? Thanks! Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
[Fedora-directory-users] Looking for copy of new mmr.pl
The link to the new version of mmr.pl at http://directory.fedoraproject.org/wiki/Howto:MultiMasterReplication is broken, and I was wondering if anyone had a copy of the mmr.pl script for Fedora DS 1.1. Thanks! Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
[Fedora-directory-users] Fedora DS Graph 1.0.0 released
I've released version 1.0 of Fedora DS Graph (formerly FDSGraph) at: http://www.stpierreconsulting.com/fedora-ds-graph-1-0-0 This is a _major_ overhaul of the old code, and includes lots of new stuff -- most notably, support for Fedora DS 1.1. (I've also tested it with Fedora DS 1.0.4.) A larger list of changes can be found on the page linked to above. Fedora DS Graph is a graphing utility for graphing connections to and operations on a Fedora Directory Server instance. I've also requested a review of the package for eventual inclusion in Fedora, so hopefully getting your hands on Fedora DS Graph should be easier. Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
[Fedora-directory-users] Request For Comment: fedora-ds-utils project
My quest to find a copy of mmr.pl last week led me to ask on IRC: [08:51] stpierre has anyone tried pulling together a collection of some of the scripts that support fds -- mmr.pl, ol-schema-migrate.pl, setupssl2.sh, etc. -- and packaging them as, say, fedora-ds-utils? The answer was no, so I've decided to take this project on. In order to make the fedora-ds-utils package as valuable as possible (and to aid my eventual request for inclusion in Fedora), I'll be enforcing some fairly strict standards for the scripts included in the package. Please read and comment on the standards listed below; once a reasonable comment period has passed (probably a week or two), I'll start redacting the various scripts to conform to the standards and, finally, release the package. Additionally, please nominate any scripts you feel should be included in the package. In addition to mmr.pl, ol-schema-migrate.pl, and setupssl2.sh, I will be including a tool for working with indexes that I wrote but never released. STANDARDS: Program aiming for inclusion in fedora-ds-utils must meet the following standards: 1. The program must implement the following flags, where appropriate: -b searchbase Search in or operate on specified base -D binddn Bind DN -h host LDAP server -H URI LDAP Uniform Resource Indentifier(s) -n instancename Fedora DS instance -p port Port on LDAP server -s scopeSearch scope --restart Restart Fedora DS without prompting -v Run in verbose mode (diagnostics to standard output) -w passwd Bind password (for simple authentication) -W Prompt for bind password -y file Read password from file -Z Start TLS -ZZ Start TLS and require successful TLS response If the program does not need a given input, it doesn't need to implement the corresponding flag. For instance, if the program does not connect to an LDAP server, it obviously doesn't need to implement the -h/-H flags. Defaults for the -b, -D, -h/-H, and -p flags should be determined first by looking in /etc/openldap/ldap.conf for the following attributes: -b: BASE -D: BINDDN -h: HOST -H: URI -p: PORT If those attributes are not set, then those options should default as follows: -b: no default -D: cn=directory manager -h: localhost -H: ldap://localhost -p: 389 Additionally, the -n flag should default to 'slapd-shorthostname', where 'shorthostname' is the short hostname of the box as returned by `hostname -s`. If the program requires two or more of any item -- for instance, ds-mmrtool connects to two Fedora DS servers to negotiate multimaster agreements -- then it may ask for those items in any reasonably intuitive manner, and needn't have defaults as specified above. 2. The program must include 'ds' as the first element in the name; for instance: - ds-mmrtool - ds-schema-migrate - ds-setup-ssl 3. The name of the program must not include a suffix denoting the language the program is written in (.sh, .pl, .py, etc.) 4. The program must ONLY produce output a) on errors; or b) with the -v flag. In the event of successful operation, no output should be produced at all. 5. The program must be capable of running completely unattended. 6. The program must not restart Fedora DS unbidden. If the program must restart Fedora DS, it may either a) prompt the user running the program; or b) provide a --restart command-line flag. 7. All dependencies of the program must be available as RPMs in the current release of Fedora Linux 8. In order to minimize dependencies, the program must be written in one of the following languages: - Perl = 5.8 - Python = 2.4 - POSIX-compliant Bourne Shell - C/C++ or any other common compiled language 9. Programs that have some value but do not yet conform to the standards may be included in the contrib/ directory of the fedora-ds-utils package. Thanks for your input! Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Re: [Fedora-directory-users] Fedora DS Graph 1.0.0 released
On Mon, 3 Mar 2008, Maxim Doucet wrote: Chris St. Pierre a écrit : Fedora DS Graph is a graphing utility for graphing connections to and operations on a Fedora Directory Server instance. I'd like to discover your program but can't find any screen-shots on your website. Is there any place where I can find some visual ? Your wish is my command. :) http://www.stpierreconsulting.com/node/18 Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Re: [Fedora-directory-users] Request For Comment: fedora-ds-utils project
Ken-- Thanks for your comments. Some counterpoints below. :) While I like the consistancy, this sort of introduces a massive documentation bug. People will read the Red Hat DS or 7.1 DS or latest DS documentation, look for (say) setup-ds-admin.pl, and it will be missing (renamed), and come right back to the mailing list asking for it again. Most of the scripts I'll be working with won't be mentioned in the official Redhat documentation; they're peripherals, not central to the operation of the DS. (E.g., setup-ds-admin.pl -- which _has_ been renamed, incidentally -- is packaged in fedora-ds-base itself.) That said, it might be a reasonable compromise to create a package that installs a script, say, ds-schema-migrate, plus a symlink to that script from ol-schema-migrate.pl, but make the script generate a warning when it's called by the old name. This should make it possible to change the existing documentation -- mostly on the Fedora DS wiki, I believe -- referring to those scripts at our leisure, while not breaking old functionality. Thoughts? I suspect the purpose of some scripts is to produce output. Heh, good point. I'll have to write that requirement a little more carefully. Also, some scripts call other perl or shell scripts, and tying up all those outputs neatly would probably involve rewriting them all. I'm still not deterred. If the programmer calls a command that generates unwanted output, it should be the job of the programmer -- not of the sysadmin -- to handle that output gracefully. OK, but hey! Don't forget us Red Hat (paying) customers. I've had many a cool new package refuse to run on Enterprise 4 because supporting packages were too old or packages weren't available. I can understand giving up on Enterprise 3, but right now E4 is still the massive user base. I actually _am_ one of those paying customers, so I feel your pain. :) That said, Fedora DS is a Fedora project, and while it'd be nice to only allow RHEL dependencies, I don't think it's reasonable for a Fedora-related project to tie itself to that (slower) release cycle. In practice, this is really only a problem where a package requires a _newer_ version of something than is available for RHEL X.Y; I've rarely run into a package available for Fedora that isn't available, prebuilt, for RHEL, whether from Dag Wieers, EPEL, CentOS Extras, or any of the other third-party repos out there. I'll add some language stating that scripts _should_ endeavor to work on all currently supported RHEL releases, but I don't think we can make this a requirement. Thanks again! Great input! Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
[Fedora-directory-users] Fedora DS Graph 1.0.1 released
Fedora DS Graph 1.0.0, released last week, has a bug that prevents SSL connections from being counted. Fedora DS Graph 1.0.1, available at http://www.stpierreconsulting.com/fedora-ds-1-0-1, fixes this bug. Thanks go to Andrey Ivanov for discovering it! Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Re: [Fedora-directory-users] Fedora DS version compatibility
On Thu, 20 Mar 2008, Luke Bigum wrote: I'm looking to upgrade some Fedora DS 1.02 servers to 1.1. We use a master-slave replicated configuration. Before I get too far into it, are there any known compatibility issues between 1.1 and 1.02? I was planning on updating one of the slaves to 1.1 first, leaving our master 1.02 server as it is for the time being. Is this possible or would I have to upgrade the master first? We've been transitioning our 1.0.4 boxes to 1.1 one at a time. We have four machines in a multimaster setup, and we've been running a mixed cluster for four weeks now, without any replication issues at all. We only use the base DS, though, so I can't comment on any of the configuration directory issues one of the other responders reported. Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Re: [Fedora-directory-users] MMR issue
Did you try the workaround in the bug report I sent to you on the Redhat list? What were your results? For reference, that bug is https://bugzilla.redhat.com/show_bug.cgi?id=233642 Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University On Fri, 20 Jun 2008, debu wrote: Hi Guys, I am stuck in a very crucial FDS server issue, it would be great if any one of you can help me somehow. We are upgrading from Fedora Directory Service from 1.0.4 to 1.1.0-3 We have one existing Server with 1.0.4 Now To one server we have initialized the data base and we were able to load the full DB. But, and when we start the replication we see the following error, and the incremental update is not happening. We are going for a multi master replication. Here is the error. On Supplier: (FDS Version 1.0.4) OS: Red Hat Enterprise Linux ES release 4 (Nahant) [17/Jun/2008:11:23:35 +051800] NSMMReplicationPlugin - agmt=cn=Replication_to_10.91.X.Y (10:): Unable to acquire replica: Excessive clock skew between the supplier and the consumer. Replication is aborting. [17/Jun/2008:11:23:35 +051800] NSMMReplicationPlugin - agmt=cn=Replication_to_10.91.X.Y (10:): Incremental update failed and requires administrator action On consumer: (FD version 1.1.0-3) OS: Red Hat Enterprise Linux Server release 5.1 (Tikanga) [17/Jun/2008:11:12:59 +051800] NSMMReplicationPlugin - conn=46251 op=1975 replica=o=TejaUsers: Unable to acquire replica: error: excessive clock skew [17/Jun/2008:11:23:34 +051800] - csngen_adjust_time: adjustment limit exceeded; value - 86401, limit - 86400 [17/Jun/2008:11:23:34 +051800] NSMMReplicationPlugin - conn=46461 op=792 replica=o=TejaUsers: Unable to acquire replica: error: excessive clock skew Now, My doubt is we succeded in a test environment with the same, with the only diference that we had the same OS in both the server, rest all same. Our servers are perfectly synced with NTP also. Please help in this scenario.. Regards ~Debajit -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Re: [Fedora-directory-users] Proposed new features for 1.3
On Tue, 31 Mar 2009, Rich Megginson wrote: Here are some features we are considering for the next major version (tentatively called 1.3). These are not in any particular order, and this is quite an ambitious list, so we're not likely to complete all of these in a single release. We would appreciate your help in prioritizing this list, filling in any missing details, helping with requirements/design/coding/testing/docs, and letting us know if there are other features which would be nice to have. The Security Enhancements section contains several particularly important items, particularly the ability to disallow plain text binds. That gets asked for quite frequently on IRC. The named pipe for logging is needed, too; I helped one FDS user who was using my Fedora DS Graph, but FDS produced such an enormous volume of log information that the Perl File::Tail module I use in Fedora DS Graph literally couldn't read the entire log before it was rotated. I remember mentioning that using a named pipe could very well solve the problem -- particularly if it could be put on a RAM disk, e.g. If syntax validation checking is added (which I support), there should be three modes, much like SELinux: Enforcing (syntax checking enabled, invalid values not allowed), Permissive (syntax checking enabled, invalid values permitted but a warning raised in the log), and Disabled. Additionally, there should be a way to check entire branches of an LDAP tree for syntax compliance -- i.e., a comprehensive auditing tool beyond just enabling Permissive mode and watching the logs. Thanks for all your hard work on this! Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Re: [389-users] Case sensitivity and FC9 389 DS packages.
On Mon, 11 May 2009, James Chavez wrote: Now If the uid is listed as Joe_Montana..and I login as Joe_Montana then the entry is recognized correctly by the sudo functions. If I login as joe_montana the sudo functions fail. Is there a way to force 389 to be case insensitive so that username or UIDs are recognized regardless of case? In the sudoers schema file (/etc/dirsrv/slapd-instance/schema/60sudo.ldif), you'll note that the sudoUser attribute has: EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch So do the sudoHost, sudoCommand, etc., attributes. If you want case-insensitive matching, you should change that to: EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch And then restart the DS. Secondly it seems the Fedora 9 newkey updates repo is broken. I upgraded all of our installations to the newest packages 2 to 3 weeks ago and i am wondering if these are still the latest packages. fedora-ds-dsgw-1.1.1-1.fc9.i386 fedora-ds-console-1.2.0-1.fc9.noarch fedora-ds-base-1.2.0-4.fc9.i386 fedora-ds-1.1.3-1.fc9.noarch fedora-ds-admin-1.1.7-3.fc9.i386 fedora-ds-admin-console-1.1.3-1.fc9.noarch Yes, those are the latest packages. Note that the fedora-ds-base package -- which has the important stuff -- and the fedora-ds-console package -- which has the shiny GUI stuff -- are both at 1.2.0, the latest version. FDS -- err, 389DS -- doesn't rev all of the package versions to track the release version, so the fedora-ds package is still at 1.1.3 while its requirements are at various other versions. Some nuts and bolts: fedora-ds is itself just a meta-package that contains nothing; it just requires other packages. So the fedora-ds package version really only needs to incremented if the requirements change. Since they didn't, it's easier for the dev team to leave what they can alone and only release new versions of packages that actually have some changed code. Make sense? Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Re: [389-users] Synching different passwords
On Tue, 2 Jun 2009, John A. Sullivan III wrote: Hello, all. It think I already know the negative answer to this question but is there a way to synchronize different password fields in 389? FreeIPA has a plugin to keep userPassword in sync with the Samba password hashes and the Kerberos password, but as far as I know, there's no generalized solution to this problem. I'd love for there to be one -- a configurable plugin or something like that -- but C isn't my forte. I think a lot of us are mucking with the same issue, just with slightly different parameters. Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Re: [389-users] Double quoted distinguished names
On Wed, 3 Jun 2009, tamarin p wrote: Hi, i apologize that i am revisiting this topic yet again but as we found out, double quoted distinguished names are no longer possible in 1.2.0. We initially discovered the problem for the aliasedobjectname class but it later turned out its a fault with double quoted dns in general and the schema violation we got for aliasedobjectname was because a doublequoted dn always leads for some bizare reason to the creation of an attribute with the double quoted part as the attr/value pair, so the schema violation was effect rather than cause.. we are also fairly certain they worked prior to this as we initially did some tests with 1.1.0, 1.1.2 and 1.1.3 without encountering into any problems with this. I was told in another thread that the double quoted syntax is deprecated and that escapes should be used instead. Is it then safe to assume that double quoted style will not be fixed (or at least have extremely low priority)? We have some clients who sometimes give us LDIFs for adding to the directory and they prefer the double quoted syntax as more easily readable. I can write convert script for them easily enough to handle the obvious cases but I won't go through the effort if there is a chance this will be fixed one minor version down the road. I just ran into the same problem, actually, and found one of your old mailing list posts on it; I'd been meaning to ask about it on the mailing list, so thanks for reminding me. :) The ns-newpwpolicy.pl script creates double-quoted DNs, which are then impossible (AFAICT) to modify. In other words, if you follow the documented procedure for creating per-user or per-subtree password policies, it doesn't work because the policy container is created with a double-quoted DN. In addition to the OP's question, what's the Right Thing to do with password policies? Will it work if I create the policy containers by hand with the hex escape syntax? Or do I need to create them by hand and populate them at creation time (since it's apparently still possible to _add_ entries with double-quoted DNs, just not modify them), and delete-and-recreate if I need to modify my policy? Thanks! Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
