[Fedora-directory-users] Gidnumber
by Brian Zuromski
I'm having problems assigning a Gidnumber to a group. Or finding out
how in the tons of documentation for that matter. I'm trying to create
what is shown below without any luck!! Can anyone help?
dn: cn=specialGroupFoo,ou=groups,dc=foo
objectClass: top
objectClass: posixGroup
cn: specialGroupFoo
gidNumber: 1001
memberUid: user1
memberUid: user2
memberUid: user3
memberUid: user4
18 years, 4 months
[Fedora-directory-users] another issue starting the console
by Craig White
I can start the console and I get a window asking me to log in but the
login window is never presented.
# cat /etc/profile.d/java.sh
JREHOME="/usr/java/jre1.5.0_06/lib/i386"
JAVA_HOME="/usr/java/jre1.5.0_06"
JAVAWSHOME="/usr/java/jre1.5.0_06/javaws"
LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$JREHOME:$JAVAWSHOME"
PATH="$PATH:/usr/java/jre1.5.0_06/bin"
export JAVA_HOME
# echo $LD_LIBRARY_PATH
:/usr/java/jre1.5.0_06/lib/i386:/usr/java/jre1.5.0_06/javaws
# echo $PATH
/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/usr/java/jre1.5.0_06/bin:/root/bin
# export LD_LIBRARY_PATH=/opt/fedora-ds/shared/lib
# ./startconsole -u admin -a http://srv1.clsurvey.com:26996/ &
nothing in /opt/fedora-ds/slapd-srv1/logs/ that suggests where the
problem might be
Is this a jre1.5.0_06 issue because on my own server, I am running
j2re-1.4.2-11.1.fc3.rf
Craig
18 years, 4 months
[Fedora-directory-users] v1.0-2 admin server as non-root user?
by Kevin M. Goess
Has anyone been able to install the admin server as a non-root user? With a
fresh install, not an upgrade, if I try to use a non-root user "ldapas"
instead then the admin server refues to start and leaves a cryptic error
message in the logs. Any suggestions?
$ setup/setup
...
Can't start Admin server [/opt/fedora-ds/start-admin > /tmp/file2dDMoZ 2>&1]
(error: No such file or directory)
You can now use the console. Here is the command to use to start the console:
cd /opt/fedora-ds
./startconsole -u admin -a http://straylight.ensenda.com:16116/
INFO Finished with setup, logfile is setup/setup.log
[/opt/fedora-ds]$ lsl -ad .
drwxr-xr-x 15 ldapas ldapas 4096 Dec 6 13:12 ./
[/opt/fedora-ds]$ sudo ./start-admin
[/opt/fedora-ds]$ telnet localhost 16116
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
[/opt/fedora-ds]$ tail admin-serv/logs/error
[Tue Dec 06 13:14:06 2005] [crit] host_ip_init(): PSET failure: Failed to
create PSET handle (pset error = )
Configuration Failed
[/opt/fedora-ds]$ grep ldapas /etc/passwd
ldapas:x:101:102::/opt/fedora-ds:/bin/bash
On a side note, is there any reason not to use the standard redhat "ldap" user
instead of "nobody" for the default suggested slapd user? My impression was
that "nobody" should not own any files on the filesystem.
--
Kevin M. Goess
(415) 277-2079
Ensenda, Inc.
18 years, 4 months
[Fedora-directory-users] How to ldapsearch password expiration data?
by Vsevolod (Simon) Ilyushchenko
Hi,
I finally found where the password expiration data are located. If I do
a database export from the GUI, I can see the entry:
***
dn:
cn="cn=nsPwPolicyEntry,uid=ilyush,ou=People,dc=cshl,dc=edu",cn=nsPwPolicyContainer,ou=People,dc=cshl,dc=edu
modifyTimestamp: 20051109200121Z
modifiersName:
uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoo
t
passwordMaxAge: 864000000
passwordWarning: 0
passwordMinAge: 0
passwordExp: on
passwordGraceLimit: 0
objectClass: ldapsubentry
objectClass: passwordpolicy
objectClass: top
cn: cn=nsPwPolicyEntry,uid=ilyush,ou=People,dc=cshl,dc=edu
creatorsName:
uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoot
createTimestamp: 20051109200121Z
nsUniqueId: 97b5d182-1dd111b2-80f8db9c-cc6f0000
***
However, if I ldapsearch -b
'cn="cn=nsPwPolicyEntry,uid=ilyush,ou=People,dc=cshl,dc=edu",cn=nsPwPolicyContainer,ou=People,dc=cshl,dc=edu'
I'm not getting any subentries:
***
# extended LDIF
#
# LDAPv3
# base
<cn="cn=nsPwPolicyEntry,uid=ilyush,ou=People,dc=cshl,dc=edu",cn=nsPwPolicyContainer,ou=People,dc=cshl,dc=edu>
with scope sub
# filter: (objectclass=*)
# requesting: ALL
#
# search result
search: 3
result: 0 Success
***
I've tried connecting both as "cn=Manager" and "uid=admin".
Is there a way to access these data programmatically using ldapsearch?
Thanks,
Simon
--
Simon (Vsevolod ILyushchenko) simonf(a)cshl.edu
http://www.simonf.com
"Think like a man of action, act like a man of thought."
Henri Bergson
18 years, 4 months
[Fedora-directory-users] problem importing sendmail.schema in fds
by basile
hi
i try to import sendmail.schema in fds and i have this error when i
restart server :
dse - The entry cn=schema in file
/opt/fedora-ds/slapd-nagios1/config/schema/63sendmail.ldif is invalid,
error code 21 (Invalid syntax) - object class sendmailMTAAlias: Unknown
allowed attribute type " sendmailMTACluster"
here is the file 63sendmail.schema
attribute sendmailMTACluster seems to be right define
and if i delete this attribute i have same error with others
#
#********************************************************************
#
dn: cn=schema
#
#********************************************************************
#
attributeTypes: (
1.3.6.1.4.1.6152.10.3.1.10
NAME 'sendmailMTACluster'
DESC 'cluster name associated with a set of MTAs'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256}
)
#
#********************************************************************
#
attributeTypes: (
1.3.6.1.4.1.6152.10.3.1.11
NAME 'sendmailMTAHost'
DESC 'host name associated with a MTA cluster'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256}
)
#
#********************************************************************
#
attributeTypes: (
1.3.6.1.4.1.6152.10.3.1.13
NAME 'sendmailMTAKey'
DESC 'key (left hand side) of an aliases or map entry'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256}
)
#
#********************************************************************
#
attributeTypes: (
1.3.6.1.4.1.6152.10.3.1.14
NAME 'sendmailMTAMapName'
DESC 'identifier for the particular map'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128}
SINGLE-VALUE
)
#
#********************************************************************
#
attributeTypes: (
1.3.6.1.4.1.6152.10.3.1.16
NAME 'sendmailMTAMapValue'
DESC 'value (right hand side) of a map entry'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
#
#********************************************************************
#
attributeTypes: (
1.3.6.1.4.1.6152.10.3.1.18
NAME 'sendmailMTAAliasGrouping'
DESC 'name that identifies a particular aliases grouping'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256}
)
#
#********************************************************************
#
attributeTypes: (
1.3.6.1.4.1.6152.10.3.1.20
NAME 'sendmailMTAAliasValue'
DESC 'value (right hand side) of an alias'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
#********************************************************************
#
attributeTypes: (
1.3.6.1.4.1.6152.10.3.1.22
NAME 'sendmailMTAClassName'
DESC 'identifier for the class'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128}
SINGLE-VALUE
)
#
#********************************************************************
#
attributeTypes: (
1.3.6.1.4.1.6152.10.3.1.23
NAME 'sendmailMTAClassValue'
DESC 'member of a class'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
#********************************************************************
#
objectClasses: (
1.3.6.1.4.1.6152.10.3.2.10
NAME 'sendmailMTA'
SUP top
STRUCTURAL
DESC 'Sendmail MTA definition'
MAY ( sendmailMTACluster $ sendmailMTAHost $ Description )
)
#
#********************************************************************
#
objectClasses: (
1.3.6.1.4.1.6152.10.3.2.11
NAME 'sendmailMTAMap'
SUP sendmailMTA
STRUCTURAL
DESC 'Sendmail MTA map definition'
MUST sendmailMTAMapName
MAY ( sendmailMTACluster $ sendmailMTAHost $ Description )
)
#
#********************************************************************
#
objectClasses: (
1.3.6.1.4.1.6152.10.3.2.12
NAME 'sendmailMTAMapObject'
SUP sendmailMTAMap
STRUCTURAL
DESC 'Sendmail MTA map object'
MUST ( sendmailMTAMapName $ sendmailMTAKey $ sendmailMTAMapValue )
MAY ( sendmailMTACluster $ sendmailMTAHost $ Description )
)
#
#********************************************************************
#
objectClasses: (
1.3.6.1.4.1.6152.10.3.2.13
NAME 'sendmailMTAAlias'
SUP sendmailMTA
STRUCTURAL
DESC 'Sendmail MTA alias definition'
MAY ( sendmailMTAAliasGrouping $ sendmailMTACluster $
sendmailMTAHost $ Description )
)
#
#********************************************************************
#
objectClasses: (
1.3.6.1.4.1.6152.10.3.2.14
NAME 'sendmailMTAAliasObject'
SUP sendmailMTAAlias
STRUCTURAL
DESC 'Sendmail MTA alias object'
MUST ( sendmailMTAKey $ sendmailMTAAliasValue )
MAY ( sendmailMTAAliasGrouping $ sendmailMTACluster $
sendmailMTAHost $ Description )
)
#
#********************************************************************
#
thanks for help
basile
18 years, 4 months
[Fedora-directory-users] "This beta software has expired"?
by Kevin Kovach
Hello,
I'm a bit confused this morning. I woke up and realized that my directory
was down, and when I tried to restart it I got the following message ...
# ./start-slapd
[05/Dec/2005:11:52:28 -0500] - ERROR: ** This beta software has expired **
Does this look familiar to anyone? I'm continuing to look into it, but if
it's something simple issue that I'm unaware of I'd appreciate any hints as
to what the problem is?
Some background information ...
I've been running Fedora Directory Server for about 5 months without any
issues. It's been running great. I recently added a root suffix to the
directory that went smoothly. I was able to use the new root without any
problems after I added it. I didn't seem to have any issues with that
change. This the only thing I've done in the past couple months.
I've just tired to save my config and back up the db with ./saveconfig,
./db2bak, ./db2ldif, and ./db2dsml and all attempts result in the same error
message.
Also, the only thing printed to the error log is the same message.
# cat errors
Fedora-Directory/7.1 B2005.201.2115
ldap.hostname.com:636 (/opt/fedora-ds/slapd-instname)
[05/Dec/2005:11:46:07 -0500] - ERROR: ** This beta software has expired **
[05/Dec/2005:11:47:44 -0500] - ERROR: ** This beta software has expired **
[05/Dec/2005:11:49:03 -0500] - ERROR: ** This beta software has expired **
[05/Dec/2005:11:52:28 -0500] - ERROR: ** This beta software has expired **
[05/Dec/2005:11:57:33 -0500] - ERROR: ** This beta software has expired **
[05/Dec/2005:11:58:30 -0500] - ERROR: ** This beta software has expired **
[05/Dec/2005:12:00:11 -0500] - ERROR: ** This beta software has expired **
I'm really at a loss as to what has expired. Does the directory have some
kind of license that has expired? Can this be a message for an expired
cert? It doesn't really sound like it, but that's the only thing I can
think of off the top of my head.
Thanks for any help and/or information.
- Kevin
18 years, 4 months
[Fedora-directory-users] Advantages of using FDS vs OpenLDAP?
by Howard Chu
> Date: Mon, 05 Dec 2005 10:18:35 -0700
> From: Richard Megginson <rmeggins(a)redhat.com>
>
> Mike Jackson wrote:
>
>
>> Howard Chu wrote:
>>
>>
>>> Sorry to poke at a moldy old thread, but I think some misconceptions
>>> need to be cleared up.
>>>
>> Hi Howard,
>> That certainly was a moldy old thread. I'm surprised it took this
>> long to catch your attention :-)
>>
I guess my attention has been elsewhere ;)
>>> I'm not here to attack FDS. I have nothing but respect for the team
>>> working on it today. But the fact that OpenLDAP developed under
>>> different conditions, with a different philosophy, is just that -
>>> philosophical difference.
>>>
>> This is one problem which I have with using OL in commercial systems:
>> developers pushing their philosophy. The preaching of philosophies is
>> a fundamental difference between open-source and commercial
>> projects/products, and fortunately not all open-source projects do it.
>> With a commercial product, the customer is always right and new
>> features (like MMR) will appear and be enabled by default with
>> sufficient customer demand.
>>
>
> I don't believe the customer is always right. A good marketing
> organization will give the customer what they ask for. A great one will
> give the customer what he/she really needs/wants, which is not always
> what the customer asks for. We were fortunate at Netscape and Red Hat
> to have a couple of great PMs, and a few good ones.
>
Indeed. In my experience on many projects, the "customer" is almost
always wrong. Fortunately for them they were usually shielded from me by
several layers of sales/marketing, and those layers got to deal with
twisting the language so that it appeared the customer was getting
exactly what they asked for, when we were just delivering what they needed.
I don't want to pollute this list with too much off-topic discussion,
but this is a key difference - OpenLDAP did not begin as a commercial
directory product, and that was not its original purpose. It was never
Kurt's goal to create a directory server that could compete with other
commercial directory servers, he just wanted something that would work
for NetBoolean's mail routing product. Symas wasn't looking to become a
commercial directory server company either, we were just looking for
something that would work for our Connexitor EMS product. I.e., OL
started as the bare necessities that a couple developers needed for
something else entirely, and the only focus of the project has been
satisfying its developers. Many people are put off by the "if you want
it, add it yourself" attitude. I personally found this attitude
attracted me to the project, because I enjoy creating code that does
what I want.
>> With an open-source project, the developers sometimes call the
>> "customers" crazy, stupid, uninformed, etc, and tell them to be quiet
>> or go away if they don't like it.
>>
>
> That happens with proprietary software just as much or more, it's just
> not as public :-) c.f. Microsoft, Oracle
>
>
LOL. Indeed, when was the last time you ever heard "you're right, we'll
fix that right away" from Microsoft...
> That being said, I have been bothered by the tone of discussion on the
> openldap lists at times, and I don't want to have that sort of
> negativity on the fedora ds lists. Perhaps it is just a difference of
> philosophy.
>
>
Newbies tend to have a rough time with OL and with the OL lists. And
teaching newbies about LDAP basics hasn't really been one of the
priorities for OL. But in general the only time I've seen real problems
has been due to folks who come onto the lists without a clue and who
steadfastly ignore all the clues given to them. Ignorance isn't a sin,
but aggressive ignorance is.
>> Since this project's software has commercial roots, and still has
>> commercial funding, thankfully you don't see much pushing of
>> philosophy here.
>>
>
> You see a different philosophy. Besides, OpenLDAP does have a
> commercial entity behind it (Symas), and they do have customers, and
> they do want to provide features and services for them.
>
Yes, and this marks a distinct change for OpenLDAP. "It works" used to
be good enough, but isn't any more. A lot of initial development was
driven purely by internal needs. The emphasis has slowly changed to
making the code enterprise-grade, and that change has been largely due
to Symas. The old codebase sucked, royally. We at Symas started
profiling the code (and developing new code profiling tools to assist),
re-factoring, ... and as a result the OL 2.1 code was 200 times faster
than 2.0. With the old philosophy probably nobody would have bothered to
investigate. But I'm a perfectionist; "it works" isn't nearly good
enough for me...
>> The biggest problem I have with OL is that the -users mailing list is
>> censored, which is sometimes used to ensure that philosophy can be
>> pushed without being questioned. I have had numerous postings to
>> openldap-users blocked, which either questioned (even indirectly) the
>> philosophy of OL or mentioned the name of another directory server.
>> I'm happy that we have freedom of speech on this list and can have
>> this discussion; it would be prohibited on openldap-users. I really
>> despise being censored, and I'm sure that many other people feel the
>> same way.
>>
>
> There are other lists that can be used to talk about other directory
> servers and how they compare to OpenLDAP e.g. the umich list, and to
> some extend the ldap-interop list. I don't fault Kurt for keeping the
> discussions germane - perhaps we will have to do the same with the
> Fedora DS lists if we become victims of our own popularity, which is a
> good problem to have :-)
>
>
I think part of the problem was that the OL list was the only place to
find free help on the entire technology, and it irked me to see my time
being wasted giving free support to people using commercial products. 1)
they paid money to a vendor already, the vendor should be supporting
them. 2) if they have money to burn, they ought to be paying me instead.
;) The fact that these other lists are active has pretty much solved
that problem.
>> Considering those two problems, I would have a difficult time saying
>> that I have nothing but respect for the *entire* OL team. However, I
>> do have a lot of respect for you because you listen to opposing views
>> with an open mind and are willing to debate them in a friendly manner.
>>
Thanks. A good debate is always nice; anyone who doesn't like
intellectual challenge shouldn't be here in the first place...
>> BR,
>> Mike
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
18 years, 4 months
[Fedora-directory-users] Advantages of using FDS vs OpenLDAP?
by Howard Chu
Sorry to poke at a moldy old thread, but I think some misconceptions
need to be cleared up.
> * From: Mike Jackson <mj sci fi>
> * Date: Fri, 08 Jul 2005 23:37:41 +0300
> Fedora Directory Server was called Netscape Directory Server until
> just recently. It was the first LDAPv3 server in the world, afaik.
> The code was commercially developed and tested for ~8 years and has
> been in use in large scale deployments all over the world for a long
> time. It has contained features for many years which OpenLDAP project
> is just now considering, e.g. multi-master replication, ability to
> alter the configuration of the running server via LDAP, in-tree
> access control, etc.
This "just now considering" is wrong. The OpenLDAP code has supported
multi-master replication and in-tree access control since 1999, very
shortly after the Project began. The design for dynamic reconfiguration
started in-house at Symas in 2002. The point wrt MMR and in-tree access
control is that the Project actively discourages their use, not that the
features don't exist in OpenLDAP.
The debates on the mailing lists going back all those years clearly show
that none of this is a new consideration. We simply don't believe that
the claimed benefits justify the risk. The point about load-balancing
writes is totally specious, and anybody who pushes that factor is just
deluded. High availability / SPOF arguments at least have some
theoretical basis, but as easily as you can say "we've never had a data
conflict problem with MMR" I can say "we've never had an SPOF issue with
standby master" and moreover, we can state with 100% certainty no
conflicts are in our data.
The use of in-tree access controls violates some basic principals of
good security design. I.e., good security comes from a top-down policy
design. Once you have the design, you need to be able to verify that the
deployed rules actually implement that design. With the centralized ACL
rules, you can mathematically prove that your deployment matches your
policy. With distributed controls that are subject to arbitrary
modification, you cannot make any definitive statements about the
security state. The key point that people miss in building distributed
systems is that you need *centralized* control, while providing
*distributed access* to those controls, otherwise manageability goes out
the window.
> Fedora is not what I would call a "specialized" LDAP server, it's
> just a full-featured, standards based, general purpose, high quality
> LDAP server. OpenLDAP is, in contrast, very specialized, having a lot
> of different types of backends in the recent versions. You can do
> some really tricky stuff with OpenLDAP that you can't do with Fedora,
> if you need that sort of tricky stuff in your architecture.
That's a very interesting way to spin things. OpenLDAP is a
full-featured, standards based, general purpose, high quality LDAP
server, that happens to include a number of powerful extras. You make it
sound like the enhancements in OpenLDAP make it unsuitable for general
use, which is untrue, since those enhancements are all modularized
features that can be ignored if unneeded.
> And the main difference for a new person like yourself is the amount
> of available documentation. Fedora is professionally and extensively
> documented, whereas OpenLDAP documentation is very scarce and terse.
Yes, the OpenLDAP documentation is sparse, and this is a fatal flaw.
Yes, what documentation exists is terse, and this is a vital strength.
Nobody likes to spend time wading thru docs, and there's nothing gained
from saying in 5 sentences what can be stated in only one. Certainly we
need to work on expanding the scope of the documentation to cover the
numerous holes. But good documentation is concise and to the point, and
the docs I've written are precise. There may be a problem with imprecise
readers, who skim and skip over things when every single word is
crucial, but that's not our fault.
I'm not here to attack FDS. I have nothing but respect for the team
working on it today. But the fact that OpenLDAP developed under
different conditions, with a different philosophy, is just that -
philosophical difference.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
18 years, 4 months