Re: [389-users] New 389 ds install - cannot logon to adm console
well hello all, seems I'm having this problem myselffresh install, and when I go to the configuration tab of the 389-console it tells me: The user uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot does not have permission to perform this operation. When I click ok, a box appears asking for DN/pass. If I put the password in the box...it continues on with no errors (thus the mind annoyance). Then again, if I just click ok and then cancel (meaning, I don't put in new credentials) the config tab works then too. I don't actually see in the logs either what it is that I'm not being allowed to do, it seems to just be a superfluous re-prompting for the password. On a lark, I tried putting in the /wrong/ password...which it did indeed not like, telling me invalid credentials. Clicked ok, then cancel...and I'm able to access the configuration tab even after putting in the wrong pass and not correcting it. I'm assuming it is just using the original credentials that should have prevented the initial error in the first place, even though I tried putting in new credentials... Again, fresh install, on a fresh build of Fedora14. I am tunneling the console, but that shouldn't matter (?). Is this just a bug in 389-console? Should I open a ticket? I'm going to continue past it, since it...doesn't seem to be stopping me from doing anything. I'm using the standard repos, everything is current: 389-admin-console-1.1.5-1.fc14.noarch 389-admin-console-doc-1.1.5-1.fc14.noarch 389-adminutil-1.1.13-1.fc14.x86_64 389-admin-1.1.13-2.fc14.x86_64 389-ds-console-1.2.3-1.fc14.noarch 389-ds-console-doc-1.2.3-1.fc14.noarch 389-console-1.1.4-1.fc14.noarch 389-ds-base-1.2.7.5-1.fc14.x86_64 389-dsgw-1.1.6-1.fc14.x86_64 389-ds-1.2.1-1.fc14.noarch Did I miss the response about what might have been causing this? Brian On Wed, Dec 1, 2010 at 4:00 AM, trisooma triso...@xs4all.nl wrote: On 11/30/2010 04:33 PM, trisooma wrote: On 11/30/2010 02:32 PM, Trisooma wrote: On 11/30/2010 10:23 PM, Rich Megginson wrote: On 11/30/2010 02:20 PM, trisooma wrote: If i am reading the code correctly (and looking at the logging below), the line that has a severity of 'crit' should dump info for the ldap server we are connecting to. In my case (and Eric's too) only 'ldap://:389' is printed; sometimes even with an odd number like 23395496 (see Eric's first post). [Tue Nov 30 22:01:43 2010] [crit] openLDAPConnection(): util_ldap_init failed for ldap://:389 [Tue Nov 30 22:01:43 2010] [warn] Unable to open initial LDAPConnection to populate LocalAdmin tasks into cache. [Tue Nov 30 22:01:44 2010] [notice] Apache/2.2.17 (Unix) configured -- resuming normal operations [Tue Nov 30 22:01:44 2010] [crit] openLDAPConnection(): util_ldap_init failed for ldap://:389 [Tue Nov 30 22:01:44 2010] [warn] Unable to open initial LDAPConnection to populate LocalAdmin tasks into cache. The code that logs this error looks like this [mod_admserv/mod_admserv.c:517] ap_log_error(APLOG_MARK, APLOG_CRIT, 0 /* status */, NULL, openLDAPConnection(): util_ldap_init failed for ldap%s://%s:%d, data-secure ? s : , data-host, data-port); It seems that the struct 'data' is not filled with the correct values. That's why I asked for your /etc/dirsrv/admin-serv/adm.conf - http://lists.fedoraproject.org/pipermail/389-users/2010-November/012548.html My bad, see http://lists.fedoraproject.org/pipermail/389-users/2010-November/012551.html First, upgrade to the latest versions of these components from the testing repo yum upgrade --enablerepo=updates-testing 389-admin 389-ds-base 389-adminutil Then, run setup-ds-admin.pl -u Then try ldapsearch -x -LLL -H ldap://icicle.phasma.nl:389/ -D uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot -w youradminpassword -s base -b cn=389 Administration Server,cn=Server Group,cn=icicle.phasma.nl,ou=phasma.nl,o=NetscapeRoot and ldapsearch -x -LLL -H ldap://icicle.phasma.nl:389/ -D uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot -w youradminpassword -s base -b cn=admin-serv-icicle,cn=389 Administration Server,cn=Server Group,cn=icicle.phasma.nl,ou=phasma.nl ,o=NetscapeRoot Using the above i can confirm that i can now use the console to log in and administer my DS (though i had to remove selinux-policy-targeted). The command 'setup-ds-admin.pl -u' ran without a hitch. the results of both ldap queries are below: [root@icicle /]# ldapsearch -x -LLL -H ldap://icicle.phasma.nl:389/ -D uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot -W -s base -b cn=389 Administration Server,cn=Server Group,cn=icicle.phasma.nl,ou=phasma.nl,o=NetscapeRoot Enter LDAP Password: dn: cn=389 Administration Server,cn=Server Group,cn=icicle.phasma.nl,ou=phasma
Re: [389-users] superior attributes (not object classes)
You can't have an attribute use an objectclass as it's superior. An attribute can only use another attribute as it's superior. The same restriction goes for an objectclass. An objectclass can only use another objectclass as it's superior. I wrote up an email about how that was just a mistake in the example, but that the original entries themselves didn't have that problem. But no, no - in my original, the attributes I was wanting to be inherited I did in fact put SUP top in them. I have no idea why I did that...I know that an attribute can't inherit from an objectclass. So apologies - for this particular issue, it was just a PEBKAC. The other issues remain and are more legit, however ;) That said, they all may boil down to the fact that the currently active 389-ds in the official Fedora repos is an alpha that snuck in. Those are the attributes from 00core.ldif that jumped in to my 99user.ldif for some reason (which I'm unsure still if I should do a bugreport for, since it only happened once) and then the 3 bug reports I put in bugzilla (625327, 625335, and 629149). I am willing to do a disaster recovery test to facilitate doing a fresh reload of everything once that alpha 389-ds package is replaced in the repos; then I can just see if those problems (two of which I can reproduce easily, the third is a problem I can't get to go away) still exist. Thanks, and sorry! Brian LaMere -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
[389-users] superior attributes (not object classes)
Regarding superior attributes, I found this email from 4 years ago: https://www.redhat.com/archives/fedora-directory-users/2006-July/msg00059.html In it, Mike said Seems that my schema conversion tool doesn't support attribute inheritance...[snip]...I will keep this in mind for a feature enhancement. rfc2252 defines superior attributes, and it was something I was using in my schema definition since I have a lot of new attributes and all but 4 of them had one of 5 different configs of EQUALITY|ORDERING and SYNTAX. Not only was it cleaner to be able to just inherit the syntax and matching rules, it also was faster ;) Obviously, it doesn't keep me from doing anything. Was this ever looked at again for a feature enhancement? Is it already available, if I do X thing? During the schema reload, I got this error (for context): dse - The entry cn=schema in file /etc/dirsrv/slapd-(server)/schema/97hosting.ldif is invalid, error code 21 (Invalid syntax) - attribute type nocastr128: Missing parent attribute syntax OID I got it because I was using SUP nocastr128 in an attributeType, after defining an attributeType of nocastr128 with the base components I wanted to inherit. Thanks, Brian LaMere ps - I have 2 more emails I'm sending; since they are on different subjects, I thought I'd break them into different emails. Please let me know if this was a bad idea and I won't do it again. -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] attributes from 00core.ldif put in 99users.ldif after schema update
On Tue, Aug 31, 2010 at 8:52 PM, Rich Megginson rmegg...@redhat.com wrote: That was an early alpha version that was only in testing and should not have been pushed to stable (not sure how that happened). I strongly encourage you to use 389-ds-base-1.2.6-1. This is now in the testing repos and will be pushed to stable at the end of this week. oops - well, maybe that will explain the other (actual) problem I had after the schema update. I'll post on that when I get back to work tomorrow and can describe it; it's something that I can only find/see within the 389-console. Yes, bugzilla does allow you to mark attachments as private. But is it possible to reproduce this issue with just some dummy data to avoid the risk entirely? And if it is indeed a bug, we should open a bugzilla for this issue. I didn't create any actual entries, it was just definitions for attributetypes and objectclasses. I don't really see much of a risk (necessarily?) unless my schema was just insanely broken; I don't use those two attributes anyway ;) happy to send the schema to whomever to try on their own, or I could just spin up a new EC2 instance and reload it fresh again and see if it happens again if loaded on an ec2 i686 instance... However, if what I'm using is an unstable version, it could just be that it was triggered by doing a reload (regardless of content), and had nothing to do with my schema at all. Is that more likely? Brian LaMere -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
