Ignore me. This was an issue with PowerShell apparently. If run from linux it works fine.
Thanks again
Ignore me. This was an issue with PowerShell apparently. If run from linux it works fine.
Thanks again
Getting:
{
"status": "Bad Request",
"message": "Failed to parse body"
}
Same command as above, changed from PUT to POST and sending request to https://my.sub.domain.tld/api/v1/domains/sub.domain.tld/config
Any ideas?
@girish Documentation specifies PUT but yeah, tried POST as well.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Error</title>
</head>
<body>
<pre>Cannot POST /api/v1/domains/sub.domain.tld</pre>
</body>
</html>
@girish Im getting the following:
curl -k -X PUT -H 'Content-Type: application/json' -H 'Authorization: Bearer APIKEYHERE' --data '{"domain":"sub.domain.tld","zone": "sub.domain.tld","provider":"route53","config": {"accessKeyId":"AKIA","secretAccessKey":"XXXXX"},"tlsConfig":{ "provider":"letsencrypt-prod","wildcard":true }}' https://my.sub.domain.tld/api/v1/domains/sub.domain.tld
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Error</title>
</head>
<body>
<pre>Cannot PUT /api/v1/domains/sub.domain.tld</pre>
</body>
</html>
But I get the following with:
curl -k -X GET -H 'Content-Type: application/json' -H 'Authorization: Bearer APIKEYHERE' https://my.sub.domain.tld/api/v1/domains
{
"domains": [
{
"domain": "sub.domain.tld",
"zoneName": "sub.domain.tld",
"provider": "route53",
"config": {}
}
]
}
Any ideas? Im sure Im just not constructing the call correctly.
My assumption is something along the lines of
{
"provider": "route53",
"config": {"accessKeyId":"AKIAXXXXXXX", "secretAccessKey":"XXXXXXXXXXXXXX"},
"wildcard": true,
"zoneName": "my.zone.name",
}
@girish unfortunately long lived keys wont work in my situation. Additionally, it is recommended by AWS to rotate them on a 90 day basis at a minimum.
Any specific example so I can see how this object is to be constructed?
thanks
Following the docs here, I have cloudron up and running with AWS route53 and all appears to be working fine. The problem comes every time I need to rotate my AWS IAM keys. Currently I am manually updating these credentials and saving them through the web UI.
Based on https://docs.cloudron.io/api.html#tag/Domains/paths/~1domains~1{domain}/put it appears that I can do this through the API, do you by change have an example of the Config parameter in use?
Im guessing the best approach to this would be to install the AWS cli on the cloudron server and call it via cron to execute the credential rotation and call the API to update the domain. Thoughts? I just want to make sure I am not missing an obvious configuration option you already have to handle such issues.
The workaround I posted above worked for me in case anyone else runs into similar issues.
@girish said in name resolution issues on fresh install:
169.254.169.253
Yes. https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html
This is what I did to get around things on fresh ubuntu 22.04 - not sure yet if best method or not.
apt install unbound -y
cat /etc/unbound/unbound.conf.d/ec2.conf
server:
val-permissive-mode: yes
forward-zone:
name: "."
forward-addr: 169.254.169.253
Then proceed with the installation as normal. Any thoughts would be greatly appreciated.
Im trying to install on a fresh ubuntu 22.04 instance hosted in EC2. Nothing special about the EC2 instance, name resolution works fine - can update the box, reach out to the internet for the cloudron-setup file etc. However, when attempting to run cloudron-setup - installation borks about midway through:
echo "==> Install collectd"
==> Install collectd
# without this, libnotify4 will install gnome-shell
apt-get install -y libnotify4 libcurl3-gnutls --no-install-recommends
Reading package lists...
Building dependency tree...
Reading state information...
libcurl3-gnutls is already the newest version (7.81.0-1ubuntu1.6).
libcurl3-gnutls set to manually installed.
The following additional packages will be installed:
libgdk-pixbuf-2.0-0 libgdk-pixbuf2.0-common
Suggested packages:
gnome-shell | notification-daemon
Recommended packages:
libgdk-pixbuf2.0-bin
The following NEW packages will be installed:
libgdk-pixbuf-2.0-0 libgdk-pixbuf2.0-common libnotify4
0 upgraded, 3 newly installed, 0 to remove and 1 not upgraded.
Need to get 174 kB of archives.
After this operation, 653 kB of additional disk space will be used.
Ign:1 http://us-east-1.ec2.archive.ubuntu.com/ubuntu jammy-updates/main amd64 libgdk-pixbuf2.0-common all 2.42.8+dfsg-1ubuntu0.2
Ign:2 http://us-east-1.ec2.archive.ubuntu.com/ubuntu jammy-updates/main amd64 libgdk-pixbuf-2.0-0 amd64 2.42.8+dfsg-1ubuntu0.2
looks like thats running from /tmp/box-src-XiBMgT/scripts/init-ubuntu.sh
, and the issue crops up right from the installation of unbound but doesnt present until the install of libnotify4, etc.
/etc/resolv.conf
before install:
nameserver 127.0.0.53
options edns0 trust-ad
search ec2.internal
and after:
nameserver 127.0.0.1
search ec2.internal
options edns0 trust-ad
any idea how to ensure unbound doesnt bork name resolution during the install?
@nebulon anything changed recently related to this? I patched glauth and authentication was working for the last few days. I rebooted the system to update OS packages and now auth is no longer working. Nothing else has changed. Just trying to limit variables and preserve the limited hair I have remaining.
Cheers
@nebulon yeah this exactly. I can use the DN instead of the UID but the problem then became the tolower() function on the cloudron side would fail. Currently I patched glauth to stop checking for bindDN being part of the baseDN but I dont think its the ideal long term solution. Im not sure what portion of your user base is using glauth and imagine its probably fairly small but it would be a big quality of life improvement for me.
Cheers for the assistance
wget https://raw.githubusercontent.com/glauth/glauth/e7195ed983715383bd5df1dc521f8c17d34d6a50/v2/sample-simple.cfg -O /tmp/ldap.cfg
the releases section has precompiled bins here https://github.com/glauth/glauth/releases/
if using docker
docker run -d --name glauth -p 389:3893 -v /tmp/ldap.cfg:/app/config/config.cfg glauth/glauth-plugins
inside cloudron
Provider: other
Server URL: ldap://127.0.0.1:389
BseDN: dc=glauth,dc=com
Filter: (objectClass=posixAccount)
Username Field: uid
Bind DN: serviceuser,dc=glauth,dc=com | cn=serviceuser,ou=svcaccts,dc=glauth,dc=com # either work
Bind Password: mysecret
save and synchronize
user accounts load into users section correctly. Logging into the accounts produces the following error in glauth:
15:52:23.394913 findUser ▶ WARN 00c "level"=2 "msg"="BindDN not part of our BaseDN" "basedn"="dc=glauth,dc=com" "binddn"="johndoe"
pcap:
15:52:23.394496 IP localhost.60316 > localhost.ldap: Flags [P.], seq 1:28, ack 1, win 512, options [nop,nop,TS val 293
1810893 ecr 2931810893], length 27
0x0000: 4500 004f 6b42 4000 4006 d164 7f00 0001 E..OkB@.@..d....
0x0010: 7f00 0001 eb9c 0185 6c39 a418 9a16 2259 ........l9...."Y
0x0020: 8018 0200 fe43 0000 0101 080a aebf e24d .....C.........M
0x0030: aebf e24d 3019 0201 0160 1402 0103 0407 ...M0....`......
0x0040: 6a6f 686e 646f 6580 0664 6f67 6f6f 64 johndoe..dogood
ldapsearch -LLL -H ldap://localhost:389 -D serviceuser,dc=glauth,dc=com -w mysecret -x -bdc=glauth,dc=com
succeeds
ldapsearch -LLL -H ldap://localhost:389 -D serviceuser -w mysecret -x -bdc=glauth,dc=com
ldap_bind: Invalid credentials (49)
ldapsearch -LLL -H ldap://localhost:3893 -D johndoe,dc=glauth,dc=com -w dogood -x -bdc=glauth,dc=com '(objectClass=posixAccount)'
succeeds if I add
[[users.capabilities]]
action = "search"
object = "*"
but I still get
ldapsearch -LLL -H ldap://localhost:389 -D johndoe -w dogood -x -bdc=glauth,dc=com '(objectClass=posixAccount)'
ldap_bind: Invalid credentials (49)
What Im looking at is potentially adding an External Directory Provider that simply appends "dc=glauth,dc=com" to the result of the search prior to the bind.
ie: johndoe@dc=glauth,dc=com or johndoe@glauth.com rather than just johndoe
@girish because I have such a low user count currently, I think I should be OK with my pagination workaround.
However, Im having a bit of a time trying to get the LDAP authentication to succeed. It works for the user I specify as the BindDN/username portion of the Connect to External Directory when this user is in the form of user@domain.tld. The search succeeds and returns the user account for testing authentication but the subsequent bind to validate authentication fails as I cannot specify user@domain.tld but instead it attempts to authenticate as just user.
On the glauth side it fails as its looking for the the BindDN to contain the BaseDN string. Is the BaseDN field in the LDAP authentication getting applied because it appears it is not when looking at /home/yellowtent/box/src/externalldap.js
.
Is there anyway to append the BaseDn to the BindDn in these cases?
The users are synchronizing but authentication is failing and Im not sure why, but I guess its a step in the right direction
Ignore me. Modifying the following lines in /home/yellowtent/box/src/externalldap.js
:
138: paged: truefalse,
157: paged: truefalse,
178: paged: truefalse,
This produced the results Im looking for. I think ....
Im looking to leverage glauth for a simple LDAP backend. I have configured this independently in several of the apps but I was hoping to be able to sync this ldap server with cloudron and just sync the apps with the cloudron server users (ldap). However Im getting the following error and I was wondering if there is an easy way to support non paged ldap results.
Nov 09 14:26:02 box:tasks update 10: {"percent":100,"result":null,"error":{"stack":"BoxError: missing paged control\n at SearchPager.<anonymous> (/home/yellowtent/box/src/externalldap.js:122:48)\n at SearchPager.emit (node:events:526:28)\n at SearchPager.emit (/home/yellowtent/box/node_modules/ldapjs/lib/corked_emitter.js:44:33)\n at SearchPager._onEnd (/home/yellowtent/box/node_modules/ldapjs/lib/client/search_pager.js:103:12)\n at EventEmitter.emit (node:events:526:28)\n at sendResult (/home/yellowtent/box/node_modules/ldapjs/lib/client/client.js:1194:22)\n at messageCallback (/home/yellowtent/box/node_modules/ldapjs/lib/client/client.js:1222:16)\n at Parser.onMessage (/home/yellowtent/box/node_modules/ldapjs/lib/client/client.js:888:14)\n at Parser.emit (node:events:526:28)\n at Parser.write (/home/yellowtent/box/node_modules/ldapjs/lib/messages/parser.js:107:8)","name":"BoxError","reason":"External Error","details":{},"message":"missing paged control","nestedError":{"stack":"PagedError: missing paged control\n at SearchPager._onEnd (/home/yellowtent/box/node_modules/ldapjs/lib/client/search_pager.js:93:17)\n at EventEmitter.emit (node:events:526:28)\n at sendResult (/home/yellowtent/box/node_modules/ldapjs/lib/client/client.js:1194:22)\n at messageCallback (/home/yellowtent/box/node_modules/ldapjs/lib/client/client.js:1222:16)\n at Parser.onMessage (/home/yellowtent/box/node_modules/ldapjs/lib/client/client.js:888:14)\n at Parser.emit (node:events:526:28)\n at Parser.write (/home/yellowtent/box/node_modules/ldapjs/lib/messages/parser.js:107:8)\n at Socket.onData (/home/yellowtent/box/node_modules/ldapjs/lib/client/client.js:875:22)\n at Socket.emit (node:events:526:28)\n at addChunk (node:internal/streams/readable:315:12)","name":"PagedError","message":"missing paged control"}}}
missing paged control
at SearchPager.<anonymous> (/home/yellowtent/box/src/externalldap.js:122:48)
at SearchPager.emit (node:events:526:28)
at SearchPager.emit (/home/yellowtent/box/node_modules/ldapjs/lib/corked_emitter.js:44:33)
at SearchPager._onEnd (/home/yellowtent/box/node_modules/ldapjs/lib/client/search_pager.js:103:12)
at EventEmitter.emit (node:events:526:28)
at sendResult (/home/yellowtent/box/node_modules/ldapjs/lib/client/client.js:1194:22)
at messageCallback (/home/yellowtent/box/node_modules/ldapjs/lib/client/client.js:1222:16)
at Parser.onMessage (/home/yellowtent/box/node_modules/ldapjs/lib/client/client.js:888:14)
at Parser.emit (node:events:526:28)
at Parser.write (/home/yellowtent/box/node_modules/ldapjs/lib/messages/parser.js:107:8)