Komplett címtáralapú megoldás Linuxszal

Vendég írta:

Mondjuk szívesen dolgoznék a grafikus admin felület elkészítésében.

Menedzselésre én ezt használom :

http://www-unix.mcs.anl.gov/~gawor/ldap/

Valami hasomlót, esetleg jobbat :?:

Hat en orultem volna egy howtonak hogy kell felrakni az egyes cuccokat.
kb olyan mint amit Boobaa csinalt a spam+viruskereso postfix-hez.

:roll:

Kezdésnek érdemes volna megpróbálni a Debian+OpenLDAP+Luma összeállítást.
A Debian alapból PAM-t használ autentikációra. Az OpenLDAP rendelkezik gyári PAM konfig file-okkal amiket csak be kell másolni az /etc/pam.d mappába. A Luma meg egy KDE-s LDAP manager SW.
A felsorolásomból egy dolog maradt ki: az LDAP séma. Erre vonatkozóan sajna nincs infóm...

Vendég írta

Olyan Linux disztibúciót keresek - remélem, nem hiába - amely úgy van kialakítva, hogy minden felhasználó, hálózati szolgáltatás (mail, proxy, samba, stb) címtár alapon van nyilvántartva, hitelesítésnek pedig kerberost használ.

A válasz :

SUSE LINUX Enterprise Server 8 :twisted:

( kb. negyedmillió forint évente )

Az idén még kapható :wink:

Pontosítok : azért hogy az stb-t is tudja , semminemű felelősséget nem vállalok...

Megjegyzés : Én nem venném meg... :D

Egy kész "komplett" openldap séma viszont engem is érdekelne...

Sziasztok, ismét itt! :)

Na LDAP-oztam picit, vannak fejlemények, eredmények, problémák, további segítségeteket szeretném kérni! :)

Légyszi ne vegye kedveteket a hosszú hozzászólás, szerettem volna teljesen bemutatni a szitut, ezt csak így tudtam! :)

Igyekeztem a sok helyzetleírás között dőlt betűkkel kiemelni a konkrét kérdéseimet.

Szóval Fedora Core 2, benne lévő LDAP-ot használtam, nem telepítgettem forrásból semmit. Nem használok (egyelőre) semmiféle titkosítást, szeretném először anélkül működni látni.
Konfigurációs fájlok a /etc/openldap alatt vannak, megmutatnám a jelenlegi slapd.conf és ldap.conf fájlt:

slapd.conf:

[code:1:1e9e9a1b13]
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/misc.schema

allow bind_v2
disallow bind_anon

pidfile /var/run/slapd.pid

access to dn=".*,dc=dyndns,dc=org" attr="userPassword"
by dn="uid=peti,ou=people,dc=dyndns,dc=org" write
by anonymous auth
by self write
by * search

access to *
by dn="uid=peti,ou=people,dc=dyndns,dc=org" write
by * read

database ldbm
suffix "dc=dyndns,dc=org"
rootdn "cn=Manager,dc=dyndns,dc=org"
rootpw {MD5}4QrcOUm6Wau+VuBX8g+IPg==
schemacheck on
directory /var/lib/ldap/dyndns

index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
[/code:1:1e9e9a1b13]

Az ldap.conf pedig:

[code:1:1e9e9a1b13]
# $OpenLDAP: pkg/ldap/libraries/libldap/ldap.conf,v 1.9 2000/09/04 19:57:01 kurt Exp $
#
# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

#BASE dc=dyndns, dc=org
suffix "dc=dyndns,dc=org"
URI ldap://monoshom.dyndns.org
pam_password exop
ldap_version 3
pam_filter objectclass=posixAccount
pam_login_attribute uid
pam_member_attribute memberuid
nss_base_passwd ou=People,dc=dyndns,dc=org
nss_base_shadow ou=People,dc=dyndns,dc=org
nss_base_group ou=Group,dc=dyndns,dc=org
nss_base_hosts ou=Hosts,dc=dyndns,dc=org

scope one
#ldap://ldap-master.example.com:666

#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
[/code:1:1e9e9a1b13]

Szerkesztettem még a /etc/nsswitch.conf fájlt, ez jelenleg ilyen (password, shadow, group részhez került hozzá az "ldap"):

[code:1:1e9e9a1b13]
#
# /etc/nsswitch.conf
#
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
#
# The entry '[NOTFOUND=return]' means that the search for an
# entry should stop if the search in the previous entry turned
# up nothing. Note that if the search failed due to some other reason
# (like no NIS server responding) then the search continues with the
# next entry.
#
# Legal entries are:
#
# nisplus or nis+ Use NIS+ (NIS version 3)
# nis or yp Use NIS (NIS version 2), also called YP
# dns Use DNS (Domain Name Service)
# files Use the local files
# db Use the local database (.db) files
# compat Use NIS on compat mode
# hesiod Use Hesiod for user lookups
# [NOTFOUND=return] Stop searching if not found so far
#

# To use db, put the "db" in front of "files" for entries you want to be
# looked up first in the databases
#
# Example:
#passwd: db files nisplus nis
#shadow: db files nisplus nis
#group: db files nisplus nis

passwd: files ldap
shadow: files ldap
group: files ldap

#hosts: db files nisplus nis dns
hosts: files dns

# Example - obey only what nisplus tells us...
#services: nisplus [NOTFOUND=return] files
#networks: nisplus [NOTFOUND=return] files
#protocols: nisplus [NOTFOUND=return] files
#rpc: nisplus [NOTFOUND=return] files
#ethers: nisplus [NOTFOUND=return] files
#netmasks: nisplus [NOTFOUND=return] files

bootparams: nisplus [NOTFOUND=return] files

ethers: files
netmasks: files
networks: files
protocols: files
rpc: files
services: files

netgroup: files

publickey: nisplus

automount: files
aliases: files nisplus
[/code:1:1e9e9a1b13]

És szerkesztettem még a /etc/pam.d/system-auth fájlt, ami pedig ilyen lett (sor végi csillaggalkiemeltem azokat a sorokat, amiket hozzáadtam, természetesen ez az eredeti konfig fájlban nincs benne):

[code:1:1e9e9a1b13]
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required /lib/security/$ISA/pam_env.so
auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
auth required /lib/security/$ISA/pam_deny.so
auth sufficient /lib/security/pam_ldap.so use_first_pass ***

account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100
account sufficient /lib/security/pam_ldap.so ***
account required /lib/security/$ISA/pam_unix.so

password requisite /lib/security/$ISA/pam_cracklib.so retry=3
password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow
password required /lib/security/$ISA/pam_deny.so
password sufficient /lib/security/pam_ldap.so use_authtok ***

session required /lib/security/$ISA/pam_limits.so
session required /lib/security/$ISA/pam_unix.so
session required /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0 ***
session optional /lib/security/pam_ldap.so ***
[/code:1:1e9e9a1b13]

Mint ebből kiderül, "dyndns.org" volt a domain név, "peti" pedig egy - elvileg - olyan felhasználó, aki mindent írhat, mindent olvashat.

Létrehoztam egy dyndns nevű könyvtárat, (chownoltam ldap.ldap-ra) a /var/lib/ldap alatt, ahova a leírások szerint az adatbázis kerül (létre is jött szépen).

Módosítottam a /usr/share/migrationtools/migrate_common.ph fájlt így:

$DEFAULT_BASE = "dc=dyndns,dc=org";
$EXTENDED_SCHEMA = 1;
$DEFAULT_MAIL_DOMAIN = "dyndns.org";
$DEFAULT_MAIL_HOST = "dyndns.org";

majd futtattam a migration szkriptet:

# export ETC_SHADOW=/etc/shadow
# cd /usr/share/migrationtools
# ./migrate_base.pl > /tmp/base.ldif
# ./migrate_group.pl /etc/group /tmp/group.ldif
# ./migrate_hosts.pl /etc/hosts /tmp/hosts.ldif
# ./migrate_passwd.pl /etc/passwd /tmp/passwd.ldif

(szépen létre is jöttek ezek az ldif fájlok)

azután be is importáltam az LDAP-ba ezeket az LDIF fájlokat:

# ldapadd -D "cn=peti,dc=dyndns,dc=org" -W -f /tmp/base.ldif
# ldapadd -D "cn=peti,dc=dyndns,dc=org" -W -f /tmp/group.ldif
# ldapadd -D "cn=peti,dc=dyndns,dc=org" -W -f /tmp/passwd.ldif
# ldapadd -D "cn=peti,dc=dyndns,dc=org" -W -f /tmp/hosts.ldif

majd konzolból simán "slapd"-vel indítottam az LDAP szervert.

Mivel ennek célja egy céges közös címjegyzék lenne, amit roaming usereknek laptopról is el kellene érniük, így nyilván anonymous hozzáférést tiltanom kellene, login név/jelszó azonosítással kellene hozzáférést engedélyeznem. IP szerint megintcsak nem járható út, hiszen dial-upról jönnek a roaming userek, amiknek éppen aktuális IP-jét nem tudhatom.
Továbbra is az az első - alap elkézelés - hogy legyen egy user, akinek minden felett joga van, írhat, olvashat, a többi felhasználó pedig csak olvashat.

Dokumentációk olvasgatása közben találkoztam olyan megfogalmazással, miszerint külön elbírálás alá esik a keresési és az olvasási jogosultság. Ezt nem teljesen értem, a kettő egymás nélkül mit ér, hogy van ez :?: (Keresni tud, de gondolom a kapott eredményt olvasni nincs joga - minek kereshet? Olvasni tud, de keresni nem, mit olvas akkor?)

Hálózatba tettem ezt a teszgépet, amin futott a Fedora és az LDAP, Windows XP-s kliensról próbálkoztam csatlakozni.

Használtam egy Java-s "LDAP browser" programot (a minek itt a honlapja:
http://www-unix.mcs.anl.gov/~gawor/ldap/download.html).
Ezzel a programmal anonymousként nem is engedett bejelentkezni, "peti" felhasználóval és egy másik átlagos jogosultságú felhasználóval igen, itt kvázi működni látszik a dolog. Ezzel a programmal minden felhasználó látja másik felhasználó adatait, de csak a saját jelszavát, amit meg is változtathat. "peti" felhasználó pedig mindenkinek jelszavát láthatja, módosíthatja.
Látszólag tehát teljesen jó a dolog, de!
Próbáltam két levelező programból is (ahonnan véglegesen is használva lenne a dolog), az egyik az XP Outlook Express-e, a másik a legutolsó verziójú, magyar nyelvű Mozilla Thunderbird volt. Nagyon különbség nem volt a kettő között, ezért csak az Outlookot írnám le:

Beállítás:

OE fut, felül "Címek" ikon (megjelenik a címjegyzék), "Eszközök" menüpont, alatta fiókok, hozzáadtam a saját LDAP kiszolgálómat. Ugyanitt ennek "Tulajdonságaira" kattintva:

Általános fül:
Címtárszolgáltatási fiók neve: proba
Kiszolgálónév: 192.168.6.101 (teszgép IP címe)
A kiszolgálóra be kell jelentkezni checkbox pipálva, alatta usernév, jelszó kitöltve, "peti" felhasználóra.

Speciális fül:
Címtárszolgáltatás (LDAP): 389 (default, ehhez nem nyúltam)
Kiszolgáló SSL hitelesítést igényel, nincs pipa.
Megjelenítendő találatok maximális száma: 100 (default, ehhez nem nyúltam)
Keresés kezdőpontja: dc=dyndns,dc=org
Egyszerű keresési szűrő használata: nincs pipa

Outlook Express-es "eredmény":

"Személyek keresése" ikon, "Speciális" fül, "Feltételek megadása" E-mail cím, tartalmazza, @, majd "Hozzáadás" gomb, utána "Keresés", eredménye:
Felbukkanó ablakban:
"Személyek keresése" a fejléc, tartalma pedig: Nincs olyan bejegyzés a címszolgáltatások között, amely megfelelne a keresési feltételeknek"
Ha bármi tetszőlegesre változtatom az LDAP fiók tulajdonságainál a felhasználó nevét, olyanra, ami nem is létező felhasználó, az eredmény ugyanez (Javas Browserbe természetesen nem tudok bejelentkezni, csak valid felhasználónévvel, jelszóval).
Ha kiveszem az Outlookból a "Kiszolgálóra be kell jelentkezni" pipát (gondolom, ekkor anonymousként próbálna bejelentkezni), akkor viszont kereséskor a következő hibaüzit adja:

Fejlécben:" Személyek keresése", üzenet pedig: "A megadott címszolgáltatás megtagadta a hozzáférést.
Ellenőrizze e címszolgáltatás tulajdonságait, és ellenőrizze, hogy a hitelesítési típus beállításai és paraméterei helyesek-e."

Magyarán bármilyen felhasználónévvel, jelszóval próbálkozom, olyannal is, aki létezik, olyannal is, aki nem, hibát ad, miszerint nincs találati eredmény a keresésre, míg ha kiveszem a loginnév/jelszó használatát, akkor elutasítja a szerver a kérést.

Konkrét kérdéseim azok lennének, hogy:
- miért nem megy? :)
- hogyhogy ugyanarról a gépről a java-s LDAP browserrel megy szépen (anonymous-t nem enged bejelentkezni, "peti" felhasználó mindent írhat, törölhet, láthat, míg mezei user csak a saját dolgait szerkesztgetheti, másokat láthat), ugyanez ldap kliens progikból (Outlook Express, Mozilla Thunderbird) nem megy?
- hogyan is működik ez esetben az authentikálás? Jól gondolom, hogy most már LDAP-ból és csakis abból authentikálja a felhasználót, ha LDAP-hoz akarok kapcsolódni és nem foglalkozik azzal, hogy létezik-e ilyen rendszerszintű felhasználó?
- slapd.conf fájlom lenne hibás? Mit és hogyan kellene módosítanom ahhoz, hogy a fentebb vázolt helyzet alakuljon ki, ugyanúgy, ahogy most a java-s browserből megy jól? (Emiatt nem vagyok teljesen biztos abban, hogy valóban a slapd.conf-ban van a hiba??)

Találtam egyébként a /etc könyvtárban is egy ldap.conf fájlt??!??, nem értem, hogy ez mit csinál itt, minden doksi, amit LDAP ügyben találtam, a /etc/openldap könyvtárra hivatkozott, meg is találtom ott a schema alkönyvtárat, slapd.conf és ldap.conf fájlt, Fedora disztribúció telepítésekor "Full"-t választottam, semmit sem telepítgettem utólag, kézzel, úgymond ezt "kaptam".

Miért van két ldap.conf fájl a rendszeremen :?:

[code:1:1e9e9a1b13]
# @(#)$Id: ldap.conf,v 1.28 2003/05/29 13:01:04 lukeh Exp $
#
# This is the configuration file for the LDAP nameservice
# switch library and the LDAP PAM module.
#
# PADL Software
# http://www.padl.com
#

# Your LDAP server. Must be resolvable without using LDAP.
# Multiple hosts may be specified, each separated by a
# space. How long nss_ldap takes to failover depends on
# whether your LDAP client library supports configurable
# network or connect timeouts (see bind_timelimit).
host 192.168.6.77

# The distinguished name of the search base.
base dc=dyndns,dc=org

# Another way to specify your LDAP server is to provide an
# uri with the server name. This allows to use
# Unix Domain Sockets to connect to a local LDAP Server.
#uri ldap://127.0.0.1/
#uri ldaps://127.0.0.1/
#uri ldapi://%2fvar%2frun%2fldapi_sock/
# Note: %2f encodes the '/' used as directory separator

# The LDAP version to use (defaults to 3
# if supported by client library)
#ldap_version 3

# The distinguished name to bind to the server with.
# Optional: default is to bind anonymously.
#binddn cn=proxyuser,dc=example,dc=com

# The credentials to bind with.
# Optional: default is no credential.
#bindpw secret

# The distinguished name to bind to the server with
# if the effective user ID is root. Password is
# stored in /etc/ldap.secret (mode 600)
#rootbinddn cn=manager,dc=example,dc=com

# The port.
# Optional: default is 389.
#port 389

# The search scope.
#scope sub
#scope one
#scope base

# Search timelimit
#timelimit 30

# Bind timelimit
#bind_timelimit 30

# Idle timelimit; client will close connections
# (nss_ldap only) if the server has not been contacted
# for the number of seconds specified below.
#idle_timelimit 3600

# Filter to AND with uid=%s
#pam_filter objectclass=account

# The user ID attribute (defaults to uid)
#pam_login_attribute uid

# Search the root DSE for the password policy (works
# with Netscape Directory Server)
#pam_lookup_policy yes

# Check the 'host' attribute for access control
# Default is no; if set to yes, and user has no
# value for the host attribute, and pam_ldap is
# configured for account management (authorization)
# then the user will not be allowed to login.
#pam_check_host_attr yes

# Check the 'authorizedService' attribute for access
# control
# Default is no; if set to yes, and the user has no
# value for the authorizedService attribute, and
# pam_ldap is configured for account management
# (authorization) then the user will not be allowed
# to login.
#pam_check_service_attr yes

# Group to enforce membership of
#pam_groupdn cn=PAM,ou=Groups,dc=example,dc=com

# Group member attribute
#pam_member_attribute uniquemember

# Specify a minium or maximum UID number allowed
#pam_min_uid 0
#pam_max_uid 0

# Template login attribute, default template user
# (can be overriden by value of former attribute
# in user's entry)
#pam_login_attribute userPrincipalName
#pam_template_login_attribute uid
#pam_template_login nobody

# HEADS UP: the pam_crypt, pam_nds_passwd,
# and pam_ad_passwd options are no
# longer supported.

# Do not hash the password at all; presume
# the directory server will do it, if
# necessary. This is the default.
#pam_password clear

# Hash password locally; required for University of
# Michigan LDAP server, and works with Netscape
# Directory Server if you're using the UNIX-Crypt
# hash mechanism and not using the NT Synchronization
# service.
#pam_password crypt

# Remove old password first, then update in
# cleartext. Necessary for use with Novell
# Directory Services (NDS)
#pam_password nds

# Update Active Directory password, by
# creating Unicode password and updating
# unicodePwd attribute.
#pam_password ad

# Use the OpenLDAP password change
# extended operation to update the password.
#pam_password exop

# Redirect users to a URL or somesuch on password
# changes.
#pam_password_prohibit_message Please visit http://internal to change your password.

# RFC2307bis naming contexts
# Syntax:
# nss_base_XXX base?scope?filter
# where scope is {base,one,sub}
# and filter is a filter to be &'d with the
# default filter.
# You can omit the suffix eg:
# nss_base_passwd ou=People,
# to append the default base DN but this
# may incur a small performance impact.
#nss_base_passwd ou=People,dc=example,dc=com?one
#nss_base_shadow ou=People,dc=example,dc=com?one
#nss_base_group ou=Group,dc=example,dc=com?one
#nss_base_hosts ou=Hosts,dc=example,dc=com?one
#nss_base_services ou=Services,dc=example,dc=com?one
#nss_base_networks ou=Networks,dc=example,dc=com?one
#nss_base_protocols ou=Protocols,dc=example,dc=com?one
#nss_base_rpc ou=Rpc,dc=example,dc=com?one
#nss_base_ethers ou=Ethers,dc=example,dc=com?one
#nss_base_netmasks ou=Networks,dc=example,dc=com?ne
#nss_base_bootparams ou=Ethers,dc=example,dc=com?one
#nss_base_aliases ou=Aliases,dc=example,dc=com?one
#nss_base_netgroup ou=Netgroup,dc=example,dc=com?one

# attribute/objectclass mapping
# Syntax:
#nss_map_attribute rfc2307attribute mapped_attribute
#nss_map_objectclass rfc2307objectclass mapped_objectclass

# configure --enable-nds is no longer supported.
# For NDS now do:
#nss_map_attribute uniqueMember member

# configure --enable-mssfu-schema is no longer supported.
# For MSSFU now do:
#nss_map_objectclass posixAccount User
#nss_map_attribute uid msSFUName
#nss_map_attribute uniqueMember posixMember
#nss_map_attribute userPassword msSFUPassword
#nss_map_attribute homeDirectory msSFUHomeDirectory
#nss_map_objectclass posixGroup Group
#pam_login_attribute msSFUName
#pam_filter objectclass=User
#pam_password ad

# configure --enable-authpassword is no longer supported
# For authPassword support, now do:
#nss_map_attribute userPassword authPassword
#pam_password nds

# For IBM SecureWay support, do:
#nss_map_objectclass posixAccount aixAccount
#nss_map_attribute uid userName
#nss_map_attribute gidNumber gid
#nss_map_attribute uidNumber uid
#nss_map_attribute userPassword passwordChar
#nss_map_objectclass posixGroup aixAccessGroup
#nss_map_attribute cn groupName
#nss_map_attribute uniqueMember member
#pam_login_attribute userName
#pam_filter objectclass=aixAccount
#pam_password clear

# Netscape SDK LDAPS
#ssl on

# Netscape SDK SSL options
#sslpath /etc/ssl/certs/cert7.db

# OpenLDAP SSL mechanism
# start_tls mechanism uses the normal LDAP port, LDAPS typically 636
#ssl start_tls
#ssl on

# OpenLDAP SSL options
# Require and verify server certificate (yes/no)
# Default is "no"
#tls_checkpeer yes

# CA certificates for server certificate verification
# At least one of these are required if tls_checkpeer is "yes"
#tls_cacertfile /etc/ssl/ca.cert
#tls_cacertdir /etc/ssl/certs

# Seed the PRNG if /dev/urandom is not provided
#tls_randfile /var/run/egd-pool

# SSL cipher suite
# See man ciphers for syntax
#tls_ciphers TLSv1

# Client certificate and key
# Use these, if your server requires client authentication.
#tls_cert
#tls_key
ssl no
pam_password md5
[/code:1:1e9e9a1b13]

Előre is köszönök minden segítséget! ;)

Hali!

http://packages.debian.org/unstable/gnome/directory-administrator
http://packages.debian.org/unstable/web/gosa
http://packages.debian.org/unstable/web/gosa-schema
http://packages.debian.org/unstable/admin/ldaptor-webui
http://packages.debian.org/unstable/web/phpgroupware-eldaptir
http://packages.debian.org/unstable/admin/webmin-ldap-useradmin

Üdv.: kismedve

Elöször is: cool hogy van kitartásod a dolgok mellett! A FC2 rossz választás volt, egy szemétdomb. Usernek jó (talán) de az SZTE rendszergazdái naponta beveszik a digitális falloszt, mert ezt kell üzemeltetniük. Szerintem próbáld debian sarge/sid -del, akkor talán többen tudnak majd segíteni (pl. algernon tudtommal debian fejlesztő).

[quote:07c7798545="gna"]Igazabol a projekt oldala valami szerver-vas gond miatt le lett allitva "ideiglenesen" aztan valahogy nem jott vissza.

A levelezolita amit azu-ek inditottak halalos csendbe burkolozott.

En pedig -remelve hogy a nyaralasok utan talan az emberek felelednek, bar nem az o:szre tettek igeretet- varom hogy ujult erovel induljon el, de a noszogatasba beleuntam. A vegen mar talan csak 3-4 ember probalt valamit, a sok jelentkezo utan. Es a szerverzes szinten alltunk de meg a csapat se allt ossze.

ENNYI

SAJNOS

Érdeklődve láttam a topicot hogy újra előkerült, jó ideje nem olvastam már. Így némi késéssel, de reagálok korábbi dolgokra.
Ami a szervert illeti, nem sikerült pótolnom, meg látva a levlistán is megmutatkozó nihil-t, már nem is erőltettem az oldal újraindítását. Bár szerintem még mindig lenne létjogosultsága ennek valamilyen formában, de ehhez kellene egy ember, aki vezérként összefog mindent legalább kezdetben. De sajnos erre nekem most sem időm, sem energiám. Ha valaki mégis úgy gondolja, hogy induljon el megint az oldal, én nyitott vagyok rá, csak szóljon...

Bocs de kezdunk elterni az eredeti celtol. Mit is akarunk csinalni?

Sztem a grafikus feliulet akkor is elegendo lesz temaba hozva ha mar van legalabb egy specifikacio mit is akarunk vezerelni.

gna
aki tegnap sokaig fennt volt mert atallt sendmail-maildirre es utana a spamszurest meg a squirrelmailt is beallitotta. jah 2GB var/spool/mail-t konvertalt kb 13perc alatt

[quote:652dc99c70="pete"]Elöször is: cool hogy van kitartásod a dolgok mellett! A FC2 rossz választás volt, egy szemétdomb. Usernek jó (talán) de az SZTE rendszergazdái naponta beveszik a digitális falloszt, mert ezt kell üzemeltetniük. Szerintem próbáld debian sarge/sid -del, akkor talán többen tudnak majd segíteni (pl. algernon tudtommal debian fejlesztő).

Hi!

Nézd, nem akarok itt distro-war-t indítani. Való igaz, vannak nehézségeim Fedora alatt, amik nagy valószínűséggel Debian alatt nem lenne probléma. De meg kell mondjam, ez visszafelé is igaz.
Leírnám itt csakis a saját észrevételeimet a Debiannal kapcsolatban:

- stable verzión kívül "éles helyzetre" mást nem tennék fel (testing vagy unstable és a szerver kifejezés nálam sehogysem fér össze). Stable: marha régi. Bármit tennék fel rá, amit nem feltétlen tartalmaz a disztrib, ezer függőséget rántana magához, amiből újabb verzió kellene, mint a meglévő, emiatt felejtős.
- telepítője - számomra - majdhogynem teljesen használhatatlan. Tény, hogy user oldalról nézve nem használok linuxot, csak szerver alkalmazásokra. Emiatt nincs akkora gyakorlatom, mint amekkora lehetne, ha azt a napi ~12 órát, amit számítógép előtt töltök, Debiannal tenném. De, ha szükségem van linuxra, mert valamit meg kell oldjak egy rajta futó alkalmazással, nincs kedvem azzal - szó szerint - fél napokat tölteni, hogy legyen egerem, ne 320x240-es felbontásban jöjjön fel a grafikus felület, tenyérnyi ikonokkal, 24x nagyobb virtuális desktoppal, mint maga a monitor
- konfigurálása, egyszerű feladatokra is rettentő macerás, sok esetben konzol szintű matatás (DSL internet pl.)

Dolgozom, nem járok már iskolába (akkor talán több időm lenne foglalkozni az egésszel), az idő pénz, sokmindent kellene csinálni, egyszerre több helyen is lenni. Sajna, nekem tényleg nem fér bele az, hogy míg a legtöbb disztribúciónak már maga a telepítője is felismeri, grafikus módban kezeli az egeret, monitort, addig akár egy fél órát is azzal tökörésszek, hogy ezt megoldjam Debian alatt. Sokmindent kínál a Fedora grafikus környezetben, beállítás szinten, amit vért izzadva hoznék össze Debian alatt. De Fedora csomagkezelése szerintem katasztrofális. Ez és csakis ez az a dolog, ami miatt néha-néha megint a Debianra gondolok.

Remélem tényleg nem indítok ezzel semmi vitát, ez csak a saját tapasztalatom volt, amit leírtam.

Maradjunk a konkrét, előző oldalon feltett kérdésnél példaként: esetleg a konfigurációs fájlok más könyvtárban való elhelyezkedésén kívül szerintem bátran kijelenthetjük, hogy a probléma és a helyzet az LDAP-pal esetemben teljesen disztribúciófüggetlen dolog, nemde :?: ;) - ezért sem értettem már eleve a hozzászólásod, miért kellene nekem ez az egész alá Debian-t húznom, hogy ugyanitt akadjak el, ugyanezt csinálja az LDAP, mint Fedora alól :?:

Attila írta:

Asszem szép álmok ezek. Mindenesetre meg kellene határozni a specifikációkat, aztán ha nincsmás, megcsinálni.

Bár ez bazi nagy falat...

Ha komolyan gondolod rám számíthatsz ( a nap 24 órából áll plussz az iccaka :wink: )

Én nem írnák új disztribet, hanem néhány kiegészítő programmal, csomaggal bővítenék egy létezőt, szívem szerint a Debiant.

pl. openldap-schema.deb, openldap-wizard.deb, openldap-manager.deb vagy vmi . ilyesmi, és így már nem is tűnik olyan nagy feladatnak...

Darkfish voltam.

Szerintem LFS-el aránylag normális munkával össze lehet rakni egy alap rendszert, abba beleépíteni a szükséges Samba-t, Bind-et, Ldap-ot és a többit. Ezzel lenne egy komplett, teljesen a célra felépített rendszered, csak a szükséges dolgokkal. Erről csinálni egy install cd-t, és már mehet is mindenhol linuxos tartomány...
Ldap sémához egy gondolat: van egy samba-tng projekt, aminek a célja egy működö WinNT server teljes körü "lemásolása" funkcióiban. Ő is használja az ldap-ot mint backendet, van is hozzá séma, talán érdemes lenne megnézni, hátha jó valamire...

üdv!

ha éppen működik a PDC-m és belépek a tartományba kiirja az XP, hogy nem találja központi profilt a szerveren
utána meg hogy a helyi profilt nem találja
mit kell ilyenkor tenni?

netlogon és profiles megosztás megvan?

Kissé leült a topic az utóbbi pár napban... Viszont hogy ne merüljön feledésbe, összeszedtem egy oldal, hogy legyen egy kiindulási pont ennek a projektnek. Elég "fapados" még az oldal, mondhatni nincs rajta szinte semmi, de első körben úgyis felmérés jön, kik vennének részt, ki mit csinálna stb. Az oldal elérhető az http://ldap.ecentrum.hu/ címen. Igyekszem némi tartalommal is feltölteni a következő napokban, és ehhez várok mindenkit, akit érdekelne egy ilyen projekt, és az abban való részvétel...

igen és login script is van meg le is fut

[quote:760efce2ca="Mono"]
Nézd, nem akarok itt distro-war-t indítani. Való igaz, vannak nehézségeim Fedora alatt, amik nagy valószínűséggel Debian alatt nem lenne probléma. De meg kell mondjam, ez visszafelé is igaz.
Leírnám itt csakis a saját észrevételeimet a Debiannal kapcsolatban:

Maradjunk a konkrét, előző oldalon feltett kérdésnél példaként: esetleg a konfigurációs fájlok más könyvtárban való elhelyezkedésén kívül szerintem bátran kijelenthetjük, hogy a probléma és a helyzet az LDAP-pal esetemben teljesen disztribúciófüggetlen dolog, nemde :?: ;) - ezért sem értettem már eleve a hozzászólásod, miért kellene nekem ez az egész alá Debian-t húznom, hogy ugyanitt akadjak el, ugyanezt csinálja az LDAP, mint Fedora alól :?:

Én már találkoztam olyannal, hogy egyik distro alatt igy, a másik alatt meg amúgy volt lefordítva valami, és ennyi pont elég volt ahhoz, hogy ne működjön minkét helyen ua. a megoldás. (Mondjátok, hogy fordítsak magam - igazatok van, csak nincs rá mindig idő hogy mindent. A kritikus appok pl. squid,apache, php és a kernel persze saját fordítás) A debian valóban lassan frissül, ebben igazad van.

A jelenlegi munkahelyemen hamarosan aktuális lesz a tömeges központi auth, amire én a lehetőségek közül (NIS, YP, LDAP, Kerberos etc.) szeretném az LDAP-ot. Viszont Debian szerver van, amit ha megjelenik, Sarge-ra frissítek/tünk. Ha a Sarge-val fut zátonyra a kísérlet, akkor megpróbálom reprodukálni a hibát és utánanézni a bajnak, de (lehetséges) Fedora-specifikus beállításokkal/hibákkal nem tudok segíteni, mert nem használok olyat és a munkáltatóm se nézné jó szemmel, ha valami mást babrálnék munkaidőben.

Kitartást és sok sikert,

[quote:51285ae486="butcher"]igen és login script is van meg le is fut

és oda is másolja a filéket kilépéskor? :)

próbáld meg letörölni a filéket, aztán be- majd kilépni.
ha odamásolja és mégsem tetszik neki akkor nem tudom.
nálam az ext3 -o user_xattr,acl -el van felcsatolva,
ami még különbség lehet.

szoval van a logon megosztás és ott egy login.cmd vagy bat mindegy
az lefutt amikor belépek
de azon nkivül nem hiszem hogy bármi is történik ott
elvileg oda kéne különböző fileokat másolnia?
az én configomba ninc silyen bejegyzés:
ext3 -o user_xattr,acl
esetleg privátba elküldhetnéd a configod egy részét
butcher@chello.hu

Hello!
[quote:8a161e7b73="butcher"]
ha éppen működik a PDC-m és belépek a tartományba kiirja az XP, hogy nem találja központi profilt a szerveren
utána meg hogy a helyi profilt nem találja
mit kell ilyenkor tenni?

Ez mar nem annyira LDAP kerdes, de ime egy lehetoseg:
http://us4.samba.org/samba/docs/man/Samba-HOWTO-Collection/ProfileMgmt.html#id2577626

Olvasd el figyelmesen a Windows XP SP1-re vonatkozo reszt, meg javaslom a netlogon-ban legyen egy Default User mappa, amiben egy default profile van (ugyanis windows innen tolti be az alapertelmezett profilt ha a gepen v. serveren nem talal profilt es a gepen nincs ilyen)

Sok sikert!

Udv.

veteem, de ez legalább sambás téma :?

Hi

Azt gondolom en is szivesen segitenek az eredmeny elereseben, bar en is csak most kezdtem el foglalkozni a temaval, de nalunk a teljes internetes hostingot szeretnenk hosszu tavon LDAP-val tamogatottan kezelni. Es itt most kb majd 1000 userrol van szo, orulunk ha meg atlatjuk :) Es a userszam csak novekszik...

Szal, ha valami kezdemenyezes van, en benne lennek

Udv

gna

Szereny szemelyes velemenyem szerint (na erre nincsen angol rovid)

Elgondolkodtato az amit irtal. Viszont hogy disztrot kellene e csinalni hozza azt nem tudom. Ha az igenyeidre (altalanos igenyekre) szabott GNU telepitest vissza tekernel telepitove attol asszem nem egy uj disztro szuletne hanem egy "appliance customized version"

Hogy ne a levegobe beszeljek, en igy kepzelnem el nalunk:
vegy egy debiant, konfigurald fel az igenyednek megfeleloen
jegyezz fel minden konfiguracios lepest amit tettel
jegyezz fel minden csomagot (forrast) amit telepitettel
majd foglald ossze magadnak hogy atlathato legyen
majd kezdd el kutatni hogyan tudnad ezeket a konfiguracios lepeseket es az altalad telepitett plusz csomagokat(tarballokat forditoscripteket) a debian telepitobe belefesulni
Keszits telepitot es probald ki
Majd modositsd a telepito beallitasait, hogy ne csak a te kornyezetedet legyen kepes beallitani hanem okos kerdesekkel mas kornyezetet is kepes legyen beallitani

Es hurra kesz a "Debain Unified LDAP Appliance"

Nagyon sok hulyeseget irtam???

gna
UI: ha ebbol lesz valami akkor a fennt emlitett DULA megnevezes az EN otletem volt senki ne felejtse

[quote:5dc4b4c584="gna"]
UI: ha ebbol lesz valami akkor a fennt emlitett DULA megnevezes az EN otletem volt senki ne felejtse

:D

[quote:488ec126cd="Luckyboy"]Kissé leült a topic az utóbbi pár napban... Viszont hogy ne merüljön feledésbe, összeszedtem egy oldal, hogy legyen egy kiindulási pont ennek a projektnek. Elég "fapados" még az oldal, mondhatni nincs rajta szinte semmi, de első körben úgyis felmérés jön, kik vennének részt, ki mit csinálna stb. Az oldal elérhető az http://ldap.ecentrum.hu/ címen. Igyekszem némi tartalommal is feltölteni a következő napokban, és ehhez várok mindenkit, akit érdekelne egy ilyen projekt, és az abban való részvétel...

Akartam regisztrálni (itt-re kattintva):

Nincsen jogosultságod ehhez a területhez.

Sajnáljuk, de ezt a területet csak regisztrált felhasználók használhatják.

Regisztrálhatod magad ingyenesen itt, utána elérhető az összes szolgáltatás korlátozások nélkül.
Köszönjük megértésedet.

[ Vissza ]

Ezért most boldogtalan vagyok :cry:

[quote:b4f8a23547="gna"]Szereny szemelyes velemenyem szerint (na erre nincsen angol rovid)

IMHO ?
:)

[quote:3bf310a425="Attila"]

Nekem ez úgy lenne frankó, hogy lenne egy CD, amit feltelepítve ezek már így működjenek, ez lenne a SZERVER CD. Néhány kezdeti adat megadása után menjen az LDAP, a Kerberos, a DNS, a levelező, a Samba, stb.
Másrészt kellene egy erre az infrastuktúrára előre beállított klienst tartalmazó CD-t is készíteni, ez lenne a KLIENS CD. Bejelentkezésnél irány a Kerberosos realm - azaz tartomány - helyben pedig csak rendszergazda fiók kellene.

Asszem szép álmok ezek. Mindenesetre meg kellene határozni a specifikációkat, aztán ha nincsmás, megcsinálni. :lol:

Bár ez bazi nagy falat...

Attila

Nem tudom, de szerintem egy ilyen esetben lehet hogy a mondo tokeletesen megfelelne... Le lehet vele menteni kompletten az adott gepet. Feltelepitesz egy szervert, s lemented, majd az adott helyen a CD-rol valo feltelepites utan mar csak minimailsan kell valtoztatni a gepen.. Ip cim, nev...

Zoli

Talan nem az AD a legjobb es legszebb pelda a cimtarazasra, hiszen az NDS korabban es IMHO "tisztabban" oldotta meg a feladatot (don't flame!)

Mas: En eddig, ha kozos cimtarrol volt szo SQL-t hasznaltam (most lehet flamelni :)) Konyebben konfiguralhatonak, atlathatobbnak tunik - tegyuk hozza - max 30 userig tudtam eddig kiprobalni es csak a szukseges szolgaltatasokra (mail, ftp, samba). Valoszinuleg nagyobb felhasznalo szamnal kijonnenek egy ilyen rendszer korlatai, ezert en is megneznek egy LDAP alapu cimtarat, hiszen az pont erre van kitalalva.

Egy ilyen projectben en is szivesen reszt veszek.

Udv,
Sallus

A kritika teljesen jogos, a problémát orvosoltam is! Köszönöm a észrevételt!

Szia!

Én szemly szerint nagyon sajnálnám ha elhalna ez a téma mert sok embernek van ilyen igénye és ahogy a linuxra/bsdre egyre több szolgáltatás kerül át, annál nagyobb igény fog jelentkezni valami hasonlóra.

Mivel sokkan küldtek linket én is küldök egyet:
http://phpldapadmin.sourceforge.net/
Ezt szerintem az eddig támasztott igényeket majdnem mindegyikét kielégíti azaz platformfüggetlen stb.

Üdv
kagy

Att: Valamit valamiért :)

Nálunk az asszony nyomul és a napi 11-12 óra munkát még a háztartás tetézi, alig látjuk egymást hétközben, chaten kommunikalunk de legalabb egy ágyban alszunk. És van fedél a fejünk felett... :)

Biztosan megértené ha csak napi 2-3 órát fordítasz is rá. És a tudás megszerzése meg egy golden-master a kézbe biztosan jó érzés lesz :D

Sztem valaki kezdje már a kezébe venni ezt mert lassan elkezdhetjük projektnek nevezni ami itt kialakul. Én nem vagyok nagy szervező sajna.

gna

[quote:e46ad54a0d="pete"][quote:e46ad54a0d="gna"]Szereny szemelyes velemenyem szerint (na erre nincsen angol rovid)

IMHO ?
:)

télleg, a humble télleg szerény... , de én magyarul is tudok :-P

gna

Vagy talán hacking van folyamatban? Vagy talán sikerült is?

Más oldalról megközelítve a kérdést: fut-e még egyáltalán ez a projekt, vagy máris hamvába halt? Mert elképzelhető, hogy például a LOK projekt is hasznát vehetné.

Sziasztok!

Picit felhoznám a topikot, ezt találtam leginkább alkalmasnak a kérdésemre, bár látom, hogy ti komolyabb dolgokat akartok véghezvinni LDAP-pal, amitől én sem zárkóznék el, de sok mindent kellene tudnom az egészről ahhoz, hogy belevágjak egy ilyesmibe.

Szóval az alap dolog, amit szeretnék a következő lenne (eddigi ismereteim alapján leginkább az LDAP kiszolgáló lenne az, amire nekem ehhez szükségem van):
Cég, ahol dolgozom két telephellyel rendelkezik, mindkettő állandó net kapcsolattal bír, üzemeltetek egy linuxos (Fedora) levelező szervert, erre gondoltam telepíteni az OpenLDAP-ot, melyhez jelenleg Outlook-kal és Outlook Expressel kapcsolódnak a felhasználók mindkét telephelyről.

Nagy, régóta húzódó problémánk (import-export cég vagyunk) egy olyan közös adatbázis, amibe csak néhány, erre kijelölt felhasználó tud írni, viszont olvasni már mindenki tudja (jogosultság szinten). Ami gyakorlatilag a céges partnereink adatait tartalmazná, egységes lenne mindenki számára. Mivel Outlookkal levelezünk, az abban rejlő címtárat gondoltam kliens oldali megjelenítésre. Outlook mindig fut minden munkaállomáson, semmivel sem tartana tovább annak címjegyzékéből kiolvasni akár csak egy telefonszámot, mint egy különálló programból megtenni mindezt.
Jó lenne továbbá, ha minden felhasználó ezentúl az LDAP kiszolgálón tarthatná a saját címjegyzékét is a mostani lokális (.WAB) címjegyzék fájlja helyett, így ez napi szinten archiválva lenne, nem lenne adatvesztés ilyen téren, ha teszemazt tönkremegy a munkaállomásban levő merevlemez.

Tudnátok nekem ebben segíteni, mégis mit, hogyan kellene tennem, hogy ezt elérjem? Jelenleg minden levelező felhasználóm linux felhasználóként van felvéve, látom a doksik alapján, hogy megoldható lehetne LDAP authentikálás is, de eléggé komplikáltnak találom a jelenlegi helyzetemből (bár nem kizárt, hogy később áttérnék erre). Kb. 30 felhasználóról van szó, akiket nem macerás felvinni "adduser"-el, linuxon csak levelezés folyik és fog is, nincs több szolgáltatás, ami miatt igencsak komoly indok lenne az egységes LDAP alapú azonosítás.

Első körben, csak az ismerkedés erejéig szeretném mindenféle kódolás nélküli verzióban egy tesztszerveren beüzemelni ezt a dolgot (ez tehát az elsődleges cél), de élesben mindenképpen SSL-en szeretném a dolgot üzemeltetni.

Minél több doksit túrok át, annál inkább belebonyolódok ebbe az egészbe, ezért kérem a tanácsotokat, első körben, ha tudtok valami leírást konkrétan "csak" erre a problémára (lehetőleg magyarul), azt nagyon megköszönném. Tovább feszítve a húrt :oops: - amennyiben nem tudtok ilyen doksiról - megtenné valamelyikőtök, hogy csinál nekem egy kis HOW-TO-t erről a dologról :oops: Nagyon sokat segítenétek vele!

Innen pedig leírnám, hogy azok alapján, amit olvastam, hogy képzelem az egészet, mit és hogyan csinálnék, így talán könnyebb a dolog.
Első körben meg kell mondjam, nem nagyon látom át ennek a működését - végsősoron ezért kérdezek.
Kiindulási alapnak az LDAP-HOGYAN doksit vettem, melyet magyar nyelvű fordításban itt találtam meg: http://tldp.fsf.hu/HOWTO/LDAP-HOWTO-hu/index.html

Mindjárt az elején kitér arra, hogy mik azok, amik szükségesek az LDAP-hoz. Ezek alapján úgy gondolom, hogy forrásból telepíteném fel a Fedora-ra az LDAP-ot.
- Több adatbázis formátumot is támogat, melyből a BDB-t hangsúlyozza ki, hogy ez az elsődlegesen támogatott. Gondoltam be is szerzem, a www.sleepycat.com oldalról, amit ez a doksi említ. Itt már akadt egy kis problémám. Ugyanis két változatban érhető el:
- With Encryption és
- Without Encryption
Mit jelent ez? Az adatok letárolása lesz titkosított formában, vagy az adatbázishoz való hozzáférés? Ha szeretném SSL csatornán elérni majd az LDAP szolgáltatást a hálózatról, attól használhatok-e még "without encryption" változatot, mert a hálózaton folyó adatforgalom SSL kapcsolat miatt kódolva lesz, de az LDAP a Berkeley DB adatbázisba már nem ír kódoltan? Fájl szinten kiolvashatóak az adatok, ha odaülök a szerverhez? Vagy ha titkosított kapcsolattal szeretném megoldani, akkor mindenképpen a "with encryption" változatú Berkeley DB kell nekem? Vagy nagyon félreértem ezt a dolgot?

- Amennyiben SSL kapcsolattal szeretném megoldani a kommunikációt, nyilván fent kell lennie az OpenLDAP fordítása előtt a gépen az OpenSSL csomagnak, ezt első körben most nem erőltetném, majd ha e nélkül látom működni.

- Továbbá, maradva a fentebb leírt igények mellett, szintén relative a doksi elején találkoztam az LDIF fájl-lal, mint fogalommal. Ha jól veszem ki, akkor ez egy lehetőség az LDAP "feltöltésére", amit az "ldapadd" utasítással tudok felvinni az adatbázisba?

Maradva az igényeknél, nálam kétfelé válnak az adatok:
- Lesznek a mezei felhasználók, akiknek hozzá kellene férniük az LDAP-hoz, megfelelő jogosultságokat adni nekik, mit olvashatnak, mit írhatnak. Lenne ugye a saját - eddig Outlookos címjegyzék fájlban tárolt személyes címjegyzékük, amihez nyilván teljes jogosultság kell, tudják írni, olvasni, törölni a sajátjukat.
- Aztán lennének a "céges" partnerek, akikből nagyon sok van, ezeket is szabályozni kellene, miket olvashatnak (itt talán nem probléma, ha minden "közös" adatot mindenki olvashat), ill. ezeket ki tudja módosítani, ki tud újabbakat hozzáadni ehhez a közös egészhez.

A doksiban, az LDIF fájl így néz ki:

[code:1:d1b790525a]dn: o=TUDelft, c=NL
o: TUDelft
objectclass: organization
dn: cn=Luiz Malere, o=TUDelft, c=NL
cn: Luiz Malere
sn: Malere
mail: malere@yahoo.com
objectclass: person[/code:1:d1b790525a]

Nekem minden linuxos felhasználómat is és minden céges partnert fel kellene vinnem így ilyen LDIF fájlban? (azt hiszem, talán ezt nem látom át az egész dologban a legjobban). Vagy csak a céges partnereket, a saját felhasználóimat nem, mert azt megoldja a linux a /etc/shadow fájl alapján? Vagy nem tudom, szóval ezt hogy....?

Jól gondolom továbbá azt, hogy az összes ilyen "ki mit írhat, ki mit olvashat" dolgot a slapd.conf fájlban kellene ez esetben megadnom (ha nem használok LDAP alapú felhasználó azonosítást, hanem maradok a rendszer szintűnél)?
Itt a doksiban erre a sorra gondolok:

[code:1:d1b790525a]access to <what> [ by <who> <accesslevel> <control> ]+[/code:1:d1b790525a]

Ahol is a "<who>" helyére szépen beírom a felhasználóm nevét? Magyarán ahágy felhasználóm van, annyi ilyen "acces to...." sorom kellene legyen a slapd.conf-ban?

Azt hiszem, már így is túl hosszú voltam, fogalmam sincs, "jó úton" járok-e a dologgal, kérlek titeket, segítsetek ebben. Nem ölbetett kézzel várom a lépésről-lépésre megoldást, csak szeretnék ez ügyben eszmét cserélni veletek, jól látom, jól gondolom a dolgokat?

Előre is köszönök minden segítséget!
(Azért továbbra is érdekel egy erről szóló doksi, ha tudtok esetleg! :) )

Remélhetőleg nem lesz elfelejtve a téma. A weblap most például nem elérhető (http://ldap.ecentrum.hu/).

Hát igen, egy ilyen összesített jogosultságkezelés úgy kell már, mint egy falat kenyér. Eddig is nagyon csodálkoztam, hogy nincs erre egy gyors, egyszerű módszer, csak félmegoldások. Egyébként én nem deb csomagokat, vagy disztribeket látok esélyesnek, hanem bármely linux/unix alá feltelepíthető alkalmazáscsomagokat.
Szerintem egy ilyet 3-4 tapasztalt rendszergazdinak+programozónak nem oylan olyan katasztrófálisan nehéz összehozni, hiszen a részegységek megvannak: alapos átgondolás, csomó vita, majd ha kész van a terv, a megvalósítás már megvalósítható :). (ezért sem értem, hogy miért nem van már ilyen). Sajna én kicsi vagyok ahoz, hogy ilyenbe belefogjak, de szívesen részt vennék egy ilyen project létrehozásában.
Mindenképpen muszály. Ahoz, hogy nagyvállalati környezetben is elterjedjen kedvenc pingvinünk, a nagyméretű, heterogén hálózatokat kezelni kell.
Emlegetve vala a grafikus felület, szvsz ez nem egy létkérdés, de ha megvan az alaprendszer, úgy is lesz egy-két front-end nekije. De egy jól összerakott rendszerrel szvsz lehet konzolban is csodát tenni.

Honsin

nemtom, de a LOK célja a közép- és általános iskolák, ott meg nem kell 30+szervert, szolgáltatást adminolni több ezer főre persze ha lenne egy kattintós vezérlőpult, az csak több novelles/windowsos rendszergazdát csábítana át.

Az alapötlet jó, tényleg jó lenne ha nem csak-linux lenne.

Akkor aszem a DULA név nem lesz helyénvaló, de azért megtartom az alapötlet jogán későbbre :D

jóétvágyat aki most ebédel....

gna

[quote:53bc21c334="gna"]jóétvágyat aki most ebédel....
gna

Köszi. :D

Hahoooo!!!

Meghalt a tema, vagy lemaradtam valamiröl?

:(
gna

az egészhez ezeket kell feltelepítened: slapd, apache | apache-ssl | apache2, php4 | libapache2-mod-php4, php4-ldap, libnss-ldap, libpam-ldap, samba-doc (3-as a séma miatt), ldap-account-manager
mindezeket a sarge-ból ajánlom, ha akarsz ssl-t is a címtárhoz.
ha ezeket feltelepítetted a további lépések:
ldap-account-manager -el a felhasználókat és a csoportokat tudod felvenni,
utána tudod mindezt használni linux alatti uid, gid feloldáshoz:
/etc/nsswitch.conf -ban írd át a passwd, group, shadow szervizeket "compat" -ról "files ldap" -ra, ekkor először megnézi a tradicionális filékben aztán fordul az címtárhoz.
ha az authentikálást is a címtáron keresztül akarod elvégezni, akkor az /etc/pam.d/ -ben levő filéket kell átírnod, bőséges példa van a libpam-ldap dokumentációs könyvtárában.
ezt lehet használni pl. pop3s, proxy, kde, képernyővédő authentikálásra
ha az e-mail aliasokat is ebből szeretnéd venni, akkor az exim4.conf.template-ban a system_aliases routerben a data = sort ki kell cserélned erre:
data = ${if eq{${lookup ldap {ldap:///uid=$local_part,ou=people,dc=májdomén,dc=hu?mail?base?(objectClass=inetOrgPerson)}{yes}{no}}}{yes} \
{${lookup ldap {ldap:///uid=$local_part,ou=people,dc=májdomén,dc=hu?mail?base?(objectClass=inetOrgPerson)}}} \
{${lookup{$local_part}lsearch*{/etc/aliases}}}}
ez azt csinálja, hogy ha van ilyen uid-ű felhasználó felvéve a címtárba akkor onnan veszi az alias-t ha nincs akkor a tradicionális /etc/aliases filéből.
ha szeretnéd tartomány vezérlőként is használni a gépet, akkor kell a samba csomag is, és ebben is be kell állítani az ldap-os (testparm -v | grep -i ldap) paramétereket. ez azért is jó, mert nem kell semmilyen más eszközt a felhasználó kezébe adni ahhoz hogy jelszót tudjon változtatni :)

ps.: még mindig nem szeretem, hogy ez a textarea nincs kihúzva az oldal széléig! ;-) (style='min-width: 100%;')

Beírnátok ebbe a fórumba mire jutottatok?
Akár skiccek is érdekelnek a "nagy" tervről :)

Nekem is vannak ötleteim, amiket félig meddig már megvalósítottam, de ilyen átfogó rendszerről, csak álmodozok :-)

Trey: kellene a hup-ra egy project development rész :-)

ui:
+1 magyar fejlesztés!

Sziasztok!

Mostanában én is hasonlókkal foglalkozom, és elég sok mindent meg lehet már most is csinálni LDAP-os alapokon! Pl. a shell userek simán authentikálhatnak a pam_ldap segítségével, a fileok jogosultsága az nss_ldap segítségével simán közös nevezőre hozható. A Samba3 is nagyon jól támogatja az LDAP-ot, valamint a fontosabb leveleződemonok is (postfix, courier pl tutira). :!:

Ami még kéne, az az, hogy a különböző demonok a beállításaikat is tudják ldapban tárolni, és máris remek lenne :D Utána persze még egy admin-felület sem ártana :roll: , és kész is kb.

az ecentrum.hu-ra meg ez az összes:
[code:1:bfd8f07f8b]asd[/code:1:bfd8f07f8b]

Talán költözik a szerver? :lol:

Találtam egy linket ami talán segíthet ha valakik neki akarnának állni: http://quark.humbug.org.au/publications/ldap/ldap-apps.pdf

Szerintem nagyon hasznos doksi!

Üdv zeller.

Valaki mondjon már valamit, hogy ezzel mi van. Volt szavazás a weblapon, hogy ki segítene, voltak is jelentkezők, de azóta semmi.

A Linuxvilágban több cikk illetve cikksorozat is foglalkozott már LDAP-pal illetve LDAP-os megoldásokkal. Talán érdemes lenne átlapozni, illetve a honlapjukról is sok cikk letölthető én most rakerestem az LDAP szóra és mindent letöltök amit azzal kapcsolatban talát.

Néhány idevonatkozó cikk címe:
- Hitelesítés LDAP használatával
- Pehelysúlyú könyvtárelérési protokoll
- Biztonságos levelezés az LDAP segítségével
- Az LDAP és a biztonság
- Könnyű álmok
- Postás a gépben: a SuSE Email Server
- Linuxos kiszolgálót mindenkinek!
Ezekben a cikkekben mindben szerepel az LDAP kereső szó.

Igazabol a projekt oldala valami szerver-vas gond miatt le lett allitva "ideiglenesen" aztan valahogy nem jott vissza.

A levelezolita amit azu-ek inditottak halalos csendbe burkolozott.

En pedig -remelve hogy a nyaralasok utan talan az emberek felelednek, bar nem az o:szre tettek igeretet- varom hogy ujult erovel induljon el, de a noszogatasba beleuntam. A vegen mar talan csak 3-4 ember probalt valamit, a sok jelentkezo utan. Es a szerverzes szinten alltunk de meg a csapat se allt ossze.

ENNYI

SAJNOS

[quote:1634f32ac4="dejo"]
- Pehelysúlyú könyvtárelérési protokoll

A magyaritas _TOBBET_ jelent tukorforditasnal!
Kulcstabla.

A projekt indulásakor kicsit szkeptikus voltam, de inkább nem rontottam a hangulatot. Elolvastam, mit akarnak. Nem volt benne semmi olyan, amit az ldap + sasl + kerberos + vmi ldap gui + kerberos (esetleg ldap) támogatás a programokba + a megfelelő séma bővítések ne fedtek volna le. Ezek pedig adottak, csak össze kell őket reszelni... Ehelyett hangzatos nevet kerestek inkább.

WEBes felület nem lenne szerecsésebb?