https://github.com/lldap/lldap logo
Powered by
TroLL - Hey! Thank you for the great work. I ju...
# troubleshooting
t
Hey! Thank you for the great work. I just want to let you know that 
lldap:2025-07-06-debian
breaks this config for Radicale: https://github.com/lldap/lldap/blob/main/example_configs/radicale.md Namely, I get an error 
[ERROR] An exception occurred during PROPFIND request on '/': invalid attribute uid
when using 
lldap:2025-07-06-debian
but 
lldap/lldap:2025-05-19-debian
works perfectly fine.
Copy code
2025-07-07T21:26:03.380816521+00:00  DEBUG    ๐Ÿ› [debug]: decided upon suite TLS13_AES_256_GCM_SHA384 | log.target: "rustls::server::hs" | log.module_path: "rustls::server::hs" | log.file: "/__w/lldap/lldap/${GITHUB_WORKSPACE}/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/rustls-0.20.9/src/server/hs.rs" | log.line: 382
2025-07-07T21:26:03.398333166+00:00  INFO     ๏ฝ‰ [info]: LDAP session start: 3fc5bf8f-25c8-44fb-8c19-64c701f55fd1
2025-07-07T21:26:03.403007277+00:00  INFO     LDAP request [ 434ms | 0.10% / 100.00% ] session_id: 3fc5bf8f-25c8-44fb-8c19-64c701f55fd1
2025-07-07T21:26:03.403045203+00:00  DEBUG    โ”โ” ๐Ÿ› [debug]:  | msg: LdapMsg { msgid: 4, op: BindRequest(LdapBindRequest { dn: "uid=read-admin,ou=people,dc=example,dc=eu", cred: LdapBindCred::Simple }), ctrl: [] }
2025-07-07T21:26:03.403055148+00:00  DEBUG    โ”โ” do_bind [ 434ms | 0.00% / 99.90% ] dn: uid=read-admin,ou=people,dc=example,dc=eu
2025-07-07T21:26:03.403088815+00:00  DEBUG    โ”‚  โ”โ” bind [ 432ms | 0.00% / 99.48% ]
2025-07-07T21:26:03.403101666+00:00  DEBUG    โ”‚  โ”‚  โ”โ” get_password_file_for_user [ 660ยตs | 0.15% ] user_id: "read-admin"
2025-07-07T21:26:03.403914355+00:00  INFO     โ”‚  โ”‚  โ”โ” ๏ฝ‰ [info]: Login attempt for "read-admin"
2025-07-07T21:26:03.403923929+00:00  DEBUG    โ”‚  โ”‚  โ”•โ” passwords_match [ 432ms | 99.33% ] username: read-admin
2025-07-07T21:26:03.835498549+00:00  DEBUG    โ”‚  โ”โ” get_user_groups [ 1.83ms | 0.42% ] user_id: "read-admin"
2025-07-07T21:26:03.838179912+00:00  DEBUG    โ”‚  โ”‚  โ”•โ” ๐Ÿ› [debug]:  | return: {GroupDetails { group_id: 3, display_name: "lldap_strict_readonly", creation_date: 2025-03-01T11:23:29.752244695, uuid: "b157607c-fc60-321b-ab4c-1f562bfcc6a3", attributes: [] }, GroupDetails { group_id: 1, display_name: "lldap_admin", creation_date: 2025-03-01T11:23:29.729415989, uuid: "9ac3c53f-eeeb-3de1-8a70-32d3e294a4ce", attributes: [] }}
2025-07-07T21:26:03.838210949+00:00  DEBUG    โ”‚  โ”•โ” ๐Ÿ› [debug]: Success!
Copy code
2025-07-07T21:26:03.838239208+00:00  DEBUG    โ”•โ” ๐Ÿ› [debug]:  | response: BindResponse(LdapBindResponse { res: LdapResult { code: Success, matcheddn: "", message: "", referral: [] }, saslcreds: None })
2025-07-07T21:26:03.846086999+00:00  INFO     LDAP request [ 489ยตs | 100.00% ] session_id: 3fc5bf8f-25c8-44fb-8c19-64c701f55fd1
2025-07-07T21:26:03.846137370+00:00  DEBUG    โ”โ” ๐Ÿ› [debug]:  | msg: LdapMsg { msgid: 5, op: SearchRequest(LdapSearchRequest { base: "", scope: Base, aliases: Always, sizelimit: 0, timelimit: 0, typesonly: false, filter: Present("objectClass"), attrs: ["subschemaSubentry", "+"] }), ctrl: [] }
2025-07-07T21:26:03.846147296+00:00  DEBUG    โ”โ” ๐Ÿ› [debug]: rootDSE request
Copy code
2025-07-07T21:26:03.846208833+00:00  DEBUG    โ”โ” ๐Ÿ› [debug]:  | response: SearchResultEntry(LdapSearchResultEntry { dn: "", attributes: [LdapPartialAttribute { atype: "objectClass", vals: ["top"] }, LdapPartialAttribute { atype: "vendorName", vals: ["LLDAP"] }, LdapPartialAttribute { atype: "vendorVersion", vals: ["lldap_0.1.0"] }, LdapPartialAttribute { atype: "supportedLDAPVersion", vals: ["3"] }, LdapPartialAttribute { atype: "supportedExtension", vals: ["1.3.6.1.4.1.4203.1.11.1", "1.3.6.1.4.1.4203.1.11.3"] }, LdapPartialAttribute { atype: "supportedControl", vals: [] }, LdapPartialAttribute { atype: "supportedFeatures", vals: ["1.3.6.1.4.1.4203.1.5.1"] }, LdapPartialAttribute { atype: "defaultNamingContext", vals: ["dc=example,dc=eu"] }, LdapPartialAttribute { atype: "namingContexts", vals: ["dc=example,dc=eu"] }, LdapPartialAttribute { atype: "isGlobalCatalogReady", vals: ["false"] }, LdapPartialAttribute { atype: "subschemaSubentry", vals: ["cn=Subschema"] }] })
2025-07-07T21:26:03.846515075+00:00  DEBUG    โ”•โ” ๐Ÿ› [debug]:  | response: SearchResultDone(LdapResult { code: Success, matcheddn: "", message: "", referral: [] })
2025-07-07T21:26:03.898107562+00:00  INFO     LDAP request [ 1.93ms | 100.00% ] session_id: 3fc5bf8f-25c8-44fb-8c19-64c701f55fd1
2025-07-07T21:26:03.898154173+00:00  DEBUG    โ”โ” ๐Ÿ› [debug]:  | msg: LdapMsg { msgid: 6, op: SearchRequest(LdapSearchRequest { base: "cn=Subschema", scope: Base, aliases: Always, sizelimit: 0, timelimit: 0, typesonly: false, filter: Equality("objectClass", "subschema"), attrs: ["objectClasses", "attributeTypes", "ldapSyntaxes", "matchingRules", "matchingRuleUse", "dITContentRules", "dITStructureRules", "nameForms", "createTimestamp", "modifyTimestamp", "*", "+"] }), ctrl: [] }
Copy code
2025-07-07T21:26:03.898163877+00:00  DEBUG    โ”โ” ๐Ÿ› [debug]: Schema request
2025-07-07T21:26:03.899522735+00:00  DEBUG    โ”โ” ๐Ÿ› [debug]:  | response: SearchResultEntry(LdapSearchResultEntry { dn: "cn=Subschema", attributes: [LdapPartialAttribute { atype: "structuralObjectClass", vals: ["subentry"] }, LdapPartialAttribute { atype: "objectClass", vals: ["top", "subentry", "subschema", "extensibleObject"] }, LdapPartialAttribute { atype: "cn", vals: ["Subschema"] }, LdapPartialAttribute { atype: "createTimestamp", vals: ["20250707212603Z"] }, LdapPartialAttribute { atype: "modifyTimestamp", vals: ["20250707212603Z"] }, LdapPartialAttribute { atype: "ldapSyntaxes", vals: ["( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )", "( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )", "( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'Integer' )", "( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' X-NOT-HUMAN-READABLE 'TRUE' )"] }, LdapPartialAttribute { atype: "attributeTypes", vals: ["( 2.0 NAME 'String' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )", "( 2.1 NAME 'Integer' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )", "( 2.2 NAME 'JpegPhoto' SYNTAX 1.3.6.1.4.1.1466.115.121.1.28 )", "( 2.3 NAME 'DateTime' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )", "( 2.4 NAME 'avatar' DESC 'LLDAP: builtin attribute' SUP JpegPhoto )", "( 2.5 NAME 'creation_date' DESC 'LLDAP: builtin attribute' SUP DateTime )", "( 2.6 NAME 'display_name'
Copy code
DESC 'LLDAP: builtin attribute' SUP String )", "( 2.7 NAME 'first_name' DESC 'LLDAP: builtin attribute' SUP String )", "( 2.8 NAME 'last_name' DESC 'LLDAP: builtin attribute' SUP String )", "( 2.9 NAME 'mail' DESC 'LLDAP: builtin attribute' SUP String )", "( 2.10 NAME 'user_id' DESC 'LLDAP: builtin attribute' SUP String )", "( 2.11 NAME 'uuid' DESC 'LLDAP: builtin attribute' SUP String )", "( 2.12 NAME 'creation_date' DESC 'LLDAP: builtin attribute' SUP DateTime )", "( 2.13 NAME 'display_name' DESC 'LLDAP: builtin attribute' SUP String )", "( 2.14 NAME 'group_id' DESC 'LLDAP: builtin attribute' SUP Integer )", "( 2.15 NAME 'uuid' DESC 'LLDAP: builtin attribute' SUP String )"] }, LdapPartialAttribute { atype: "objectClasses", vals: ["( 3.0 NAME ( 'inetOrgPerson' 'posixAccount' 'mailAccount' 'person' ) DESC 'LLDAP builtin: a person' STRUCTURAL MUST ( mail $ user_id ) MAY ( avatar $ creation_date $ display_name $ first_name $ last_name $ uuid ) )", "( 3.1 NAME ( 'groupOfUniqueNames' 'groupOfNames' ) DESC 'LLDAP builtin: a group' STRUCTURAL MUST ( display_name ) MAY ( creation_date $ group_id $ uuid ) )"] }, LdapPartialAttribute { atype: "subschemaSubentry", vals: ["cn=Subschema"] }] })
2025-07-07T21:26:03.900312127+00:00  DEBUG    โ”•โ” ๐Ÿ› [debug]:  | response: SearchResultDone(LdapResult { code: Success, matcheddn: "", message: "", referral: [] })
n
@T0by I think that's for you ๐Ÿ˜‰ It seems the uid attribute is missing
t
Ohno, I'll have a look at it in a bit
Hmm, I can't seem to replicate your issue. Did you do anything in particular to trigger the Subschema request?
n
Am I reading it right that the uid attribute is missing? Let's start with that
t
Well if I'm correct uid is not really an attribute, similar to ou|cn|dc and so on
n
They sent
Copy code
SearchRequest(LdapSearchRequest { base: "cn=Subschema", scope: Base, aliases: Always, sizelimit: 0, timelimit: 0, typesonly: false, filter: Equality("objectClass", "subschema"), attrs: ["objectClasses", "attributeTypes", "ldapSyntaxes", "matchingRules", "matchingRuleUse", "dITContentRules", "dITStructureRules", "nameForms", "createTimestamp", "modifyTimestamp", "*", "+"] }), ctrl: [] }
Isn't it? Aren't they all?
Maybe not the DN, but cn and uid are attributes, I believe
What does openldap return, if you have a server handy?
t
Hmm okay then you might be correct, when doing a subschema request to openldap I also didn't get 
uid
, closest I got was uidNumber, but I think that's something different
n
Yeah, uid is not mandatory
But cn is an attribute
And do is uid, I'm pretty sure
And I don't know if you had that, but I think that technically member and maybe memberOf are also attributes
t
I mean we could easily add the uid to the subschema response, but it might be good to comprise a list of 'missing' attributes then
n
Basically, I think it should be everything that can get returned in an LDAP query, AFAIU
Oh, DN is also an attribute
t
Maybe we should discuss to what server implementation we want to adhere to
n
Do they disagree?
I'd tend to say openLDAP
t
I think I figured it out, OpenLDAP seems to return *object, so uidObject, dcObject etc.
n
Maybe they also have aliases for these?
t
Not sure, but with ldap servers you never know๐Ÿ˜›
Copy code
attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domainComponent' ) DESC 'RFC1274/2247: domain component' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

attributeTypes: ( 0.9.2342.19200300.100.1.1 NAME ( 'uid' 'userid' ) DESC 'RFC4519: user identifier' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
I think we should indeed implement these
And some more, I'll make a list of missing attributes as you said
forget this, I was looking in the wrong place
What's easiest, open a new PR to add these to the subschema?
n
Yep
t
PR is open: https://github.com/lldap/lldap/pull/1204 @TroLL Any chance you would be able to test if this fixes your issue?
t
I will test in 6 hours perhaps
@T0by I guess I have to publish my own docker image to test this from the branch or are there any easier options?
t
Do you by any chance have rust installed on your system?
t
nope
t
Then probably building a docker image is easiest
t
ok, let's see
t
You need any help with that?
t
I will let you know if I have any problems. It should be fine as long as it is usual docker image building :D
t
As far as I know the Dockerfile in the root should work just fine
t
> [+] Building 2450.1s (11/25)
:D
n
It's not regularly tested, so I wouldn't be surprised if it required a rustc version bump
But the good thing is that the dependencies are cached, so the next time you have to rebuild the container, you'll only build LLDAP
t
Yeah, understandable
Just a bit surprised it takes that long :D
n
We're not going for minimal dependencies ๐Ÿ˜„
Did it finish compiling? :p
t
haha, nope :DD
n
My God, are you running this on a potato?! It shouldn't take that long...
t
i6500
def not a new cpu but no idea why it takes so long
n
It shouldn't be that bad... Maybe there's something about the top level docker file that messes up things
t
๐Ÿคทโ€โ™‚๏ธ
n
ยฏ\_(ใƒ„)_/ยฏ
t
well, let's hope it finishes compiling at some point
t
Now I'm curious, I've also started a compile:D
t
:DDD
t
I'm assuming there is not a way to somehow extract the image from the GH actions workflow unless the PR is merged right? @nitnelave
n
That's a good question, and I don't know the answer. That would be GH specific internals, looking at the temporary arrifacts
t
On my machine it has failed after 1100s:
Copy code
docker
81.55    Compiling lldap v0.6.2-alpha (/app/server)
577.9     Finished `release` profile [optimized] target(s) in 9m 03s
581.5 [INFO]: Checking for the Wasm target...
581.7 [INFO]: Compiling to Wasm...
582.0    Compiling lldap_auth v0.6.0 (/app/crates/auth)
582.0    Compiling lldap_frontend_options v0.1.0 (/app/crates/frontend-options)
582.0    Compiling lldap_validation v0.6.0 (/app/crates/validation)
582.6    Compiling lldap_app v0.6.2-alpha (/app/app)
627.2     Finished `release` profile [optimized] target(s) in 45.43s
627.3 [INFO]: Installing wasm-bindgen...
631.8 Error: No such file or directory (os error 2)
631.8 Caused by: No such file or directory (os error 2)
631.8 gzip: pkg/lldap_app_bg.wasm: No such file or directory
t
Still compiling for me
n
Otherwise, you know, don't use docker
cargo run -- --verbose
is enough
t
Very true
t
lol
same
failed
n
๐Ÿ˜ฆ
t
i mean, compilation failed
n
Yeah, I got that
t
is compilation going to be much faster? especially on pi 4 :D
n
Not really, no ๐Ÿ˜„
Yeah, I guess the pi is the bottleneck
t
I could compile it with my i6500 but I am not sure I have another 14000 sec :DD
nvm, compiling, let's see
probably could forward some ports for a test if it takes reasonable amount of time
> $ cargo run -- --verbose > > Running 
target/debug/lldap --verbose
> error: unexpected argument '--verbose' found > tip: a similar argument exists: '--version' > Usage: lldap --version > For more information, try '--help'.
n
ah yeah you need an extra "run" after the first double dash
cargo run -- run --verbose
t
> 2025-07-08T16:29:08.315405085+00:00 DEBUG โ”โ” ๐Ÿ› [debug]: | msg: LdapMsg { msgid: 1, op: BindRequest(LdapBindRequest { dn: "uid=read-admin,ou=people,dc=example,dc=eu", cred: LdapBindCred::Simple }), ctrl: [] } > 2025-07-08T16:29:08.315459714+00:00 DEBUG โ”โ” do_bind [ 134ยตs | 18.50% ] dn: uid=read-admin,ou=people,dc=example,dc=eu > 2025-07-08T16:29:08.315709008+00:00 DEBUG โ”•โ” ๐Ÿ› [debug]: | response: BindResponse(LdapBindResponse { res: LdapResult { code: NamingViolation, matcheddn: "", message: "Not a subtree of the base tree", referral: [] }, saslcreds: None })
can it be related to fix or probably my setup is broken? :D
t
DId you port your config to the lldap directory?
t
i created it from scratch
used ldap instead of ldaps
let me check once again
t
I am not sure if the '-' is allowed in an attribute value, maybe that's it?
t
how can I start frontend when not in docker?
i ran build.sh but still just black screen
t
Did you follow what it sayds there?
t
yep :D
t
Okay cool, maybe browser cache?
t
Rather not
> 2025-07-08T16:41:06.717047215+00:00 DEBUG โ”โ” ๐Ÿ› [debug]: error handling /pkg/lldap_app.js: No such file or directory (os error 2) | log.target: "actix_files::service" | log.module_path: "actix_files::service" | log.file: "/home/user/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/actix-files-0.6.6/src/service.rs" | log.line: 56
t
Lol what
t
T_T
ok, let me try something
yay
seems to work!
at least I am able to login to radicale now :D
thus, the PR seems to have fixed the issue
t
Do you also see the subschema request in LLDAP log?
t
This? > 2025-07-08T17:15:14.720015282+00:00 DEBUG โ”โ” ๐Ÿ› [debug]: | msg: LdapMsg { msgid: 6, op: SearchRequest(LdapSearchRequest { base: "", scope: Base, aliases: Always, sizelimit: 0, timelimit: 0, typesonly: false, filter: Present("objectClass"), attrs: ["subschemaSubentry", "+"] }), ctrl: [] }
n
That and the response
t
Copy code
2025-07-08T17:15:11.072029553+00:00  INFO     LDAP request [ 1.07ms | 100.00% ] session_id: e22c6d4b-bd89-4121-b891-2bc16cd7af2b
2025-07-08T17:15:11.072132349+00:00  DEBUG    โ”โ” ๐Ÿ› [debug]:  | msg: LdapMsg { msgid: 2, op: SearchRequest(LdapSearchRequest { base: "", scope: Base, aliases: Always, sizelimit: 0, timelimit: 0, typesonly: false, filter: Present("objectClass"), attrs: ["subschemaSubentry", "+"] }), ctrl: [] }
2025-07-08T17:15:11.072191440+00:00  DEBUG    โ”โ” ๐Ÿ› [debug]: rootDSE request
2025-07-08T17:15:11.072335124+00:00  DEBUG    โ”โ” ๐Ÿ› [debug]:  | response: SearchResultEntry(LdapSearchResultEntry { dn: "", attributes: [LdapPartialAttribute { atype: "objectClass", vals: ["top"] }, LdapPartialAttribute { atype: "vendorName", vals: ["LLDAP"] }, LdapPartialAttribute { atype: "vendorVersion", vals: ["lldap_0.6.2-alpha"] }, LdapPartialAttribute { atype: "supportedLDAPVersion", vals: ["3"] }, LdapPartialAttribute { atype: "supportedExtension", vals: ["1.3.6.1.4.1.4203.1.11.1", "1.3.6.1.4.1.4203.1.11.3"] }, LdapPartialAttribute { atype: "supportedControl", vals: [] }, LdapPartialAttribute { atype: "supportedFeatures", vals: ["1.3.6.1.4.1.4203.1.5.1"] }, LdapPartialAttribute { atype: "defaultNamingContext", vals: ["dc=example,dc=eu"] }, LdapPartialAttribute { atype: "namingContexts", vals: ["dc=example,dc=eu"] }, LdapPartialAttribute { atype: "isGlobalCatalogReady", vals: ["false"] }] })
2025-07-08T17:15:11.072917173+00:00  DEBUG    โ”•โ” ๐Ÿ› [debug]:  | response: SearchResultDone(LdapResult { code: Success, matcheddn: "", message: "", referral: [] })
n
Ah sorry, that's the root dse. There should be another one similar just below, even longer
t
This one
t
I can't see the line that would start with 
Schema request
vOv
n
Interesting... Maybe it cached the attributes? That would make sense
t
can I reset cache?
or what do we test exactly?
n
That would be on the client (Radicale) side
t
the filter is like that: 
ldap_filter = (&(uid={0})(|(memberOf=cn=radicale,ou=groups,dc=example,dc=eu)(memberOf=cn=lldap_admin,ou=groups,dc=example,dc=eu)))
do we test and/or?
n
I expect that the fix worked, I was just curious to see the schema response to make sure. But yeah, if it's too hard to figure out, no worries. It's working, that's the main thing
t
I will let you know if there is anything wrong then :D
Thank you very much for help @nitnelave @T0by
t
I saw this exact same behaviour when I tried to test, but nitnelave might be right with the caching theory
I'll verify just to be sure, I can easily rebuild the radicale docker container I'm using
PreviousNext
Powered by