I've packaged openHab Cloud app, it can be built from
https://git.cloudron.io/vladimir.d/openhab-cloud
Comments are very welcome.
I've packaged openHab Cloud app, it can be built from
https://git.cloudron.io/vladimir.d/openhab-cloud
Comments are very welcome.
Mailpiler app for cloudron is here, built based on the original docker configuration.
https://git.cloudron.io/vladimir.d/mailpiler
Comments are very welcome.
We've created an ElasticSearch app for Cloudron.
https://git.cloudron.io/vladimir.d/elasticsearch
Comments are welcome!
@nebulon Yes, it's the instance you have SSH access.
We understand it's a temporary workaround and there could be upgrade issues (re-applying the patch), just need this done as soon as possible.
Later we can look at packaging of some LDAP proxy app or using external LDAP or wait when you implement a solution in the mainstream.
Thanks a lot!
ps. just sent details by email.
@girish works now, thank you!
The app has been pushed to git.cloudron.io.
@timconsidine I've updated Dockerfile
to fix all building issues you faced with. After that everything went just fine on a fresh cloned copy.
@timconsidine said in Mailpiler - self hosted email archive:
Blundering around in the dark, but I notice that
start.sh
has on line 53local SSL_CERT_DATA="/C=US/ST=Denial/L=Springfield/O=Dis/CN=www.example.com"
Should this not reference the Cloudron variable for location ?
When tls
add-on is enabled in the manifest, the script doesn't generate a self signed certificate and uses the Cloudron certificate of the primary domain. I've amended it to use $CLOUDRON_APP_DOMAIN
variable.
@timconsidine said in Mailpiler - self hosted email archive:
Successfully built and pushed to repository (docker in my case).
App installed on Cloudron w/o hassle .... but hangs in 'starting' mode.
So I uninstalled and triedcloudron install --image <repo>/<image>:<tag>
without the --no-wait option.
This installs but similarly gets stuck=> Wait for health check ............................^C
Out of my depth now. What to check / amend ?
It doesn't get stuck for me - I've tried to build&install the app with the recent changes.
I guess there is an issue with piler
or nginx
directories in /etc/, probably a wrong path or an invalid symlink or so.
You need to look at the app logs to see the issue.
@girish It still needs multiple postgresql database support (two databases for the app).
https://forum.cloudron.io/topic/4989/postgresql-multiple-databases-support
Hi,
We need to run Live index service for full-text search so I suggest adding the ability to configure supervisord in the application.
Here is the patch I propose to include into the mainstream:
https://git.cloudron.io/vladimir.d/nextcloud-app/-/merge_requests/1/diffs
In this case we will be able to create our own config to run indexing service using supervisor, e.g.
/app/data/supervisor/conf.d/fulltextsearch_index.conf
[program:fulltextsearch_index]
directory=/app/code
user=www-data
command=/usr/bin/php /app/code/occ fulltextsearch:live -q
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0
@girish could it be related to the number of files in the archive?
It fails to unpack custom 67.zip
containing 8400 files.
It unpacks when we randomly delete files from the archive down to 7830 files.
Also it doesn't seem related to the archive size, as I tried to unpack archives of different sizes (but containing just a few files) and it worked just fine.
Hi,
Any plans to make multipleDatabases
option available for postgresql
add-on in the same was as it's for mysql
add-on?
Thanks!
@nebulon it seems 7.2.2 is still affected. We faced with the same issue and resolved it by restating the mail service.
@girish Nextcloud-annotate needs the following dependencies installed in Nextcloud app.
DEPENDENCIES:
svg2pdf
pdftk
gs
@girish here is some initial work.
https://git.cloudron.io/vladimir.d/mailpiler
TBH I didn't have a chance to complete it yet, I think the issue described here still needs to be addressed.
@girish I used 'Syncronize' button nothing else.
Did you have a chance to reproduce the group assignment issue on our server?
@luckow we have created Cloudron users
group in UCS and put some users to the group.
On the Connect an External Directory section on Cloudron we have configured to import users and groups from UCS.
Users and Groups are imported in Cloudron.
But it fails to assign Test.Test1
user to groups. If we rename Test.Test1
username to lowercase as test.test1
, it starts working properly - see test.test
user on the screenshots.
I suspect there is a bug or misconfiguration somewhere in Cloudron.
We cannot rename real usernames to lower case due to our company policy.
We are trying to link Univention LDAP as External Directory and I noticed that it doesn't import group memberships properly.
It looks like it's case sensitive issue, when I import test.test
user, it puts the user into a group properly.
Mar 30 12:50:12 box:externalldap syncUsers: [adding user] username=test.test email=test.test@dev.mynet displayName=test test
Mar 30 12:50:12 box:externalldap syncUsers: done
...
Mar 30 12:50:12 box:tasks update 4074: {"percent":68,"message":"Syncing... uni-all-cloudron-users"}
Mar 30 12:50:12 box:externalldap syncGroups: [up-to-date group] groupname=uni-all-cloudron-users
Mar 30 12:50:12 box:externalldap syncGroups: sync done
...
Mar 30 12:50:12 box:externalldap syncGroupUsers: Sync users for group uni-all-cloudron-users
Mar 30 12:50:12 box:externalldap syncGroupUsers: Group uni-all-cloudron-users has 2 members.
Mar 30 12:50:12 box:externalldap ldapGetByDN: Get object at uid=test.test,ou=Users,dc=dev,dc=mynet
Mar 30 12:50:12 box:externalldap syncGroupUsers: Found member object at uid=test.test,ou=Users,dc=dev,dc=mynet adding to group uni-all-cloudron-users
If I rename it to Test.Test
it fails to import.
Mar 30 12:12:37 box:tasks update 4068: {"percent":30,"message":"Syncing... Test.Test"}
Mar 30 12:12:37 box:externalldap syncUsers: [adding user] username=Test.Test email=test.test@dev.mynet displayName=test test
Mar 30 12:12:37 box:externalldap syncUsers: done
...
Mar 30 12:12:37 box:externalldap syncGroupUsers: Group uni-all-cloudron-users has 2 members.
Mar 30 12:12:37 box:externalldap ldapGetByDN: Get object at uid=Test.Test,ou=Users,dc=dev,dc=mynet
Mar 30 12:12:37 box:externalldap syncGroupUsers: Found member object at uid=Test.Test,ou=Users,dc=dev,dc=mynet adding to group uni-all-cloudron-users
Mar 30 12:12:37 box:externalldap syncGroupUsers: Failed to get user by username Test.Test User not found
I can get the same data using ldapsearch
using both test.test
and Test.Test
from Univention LDAP.
We need to make External Directory synchronisation working with usernames in Test.Test
format.
@girish said in LDAP not exposing outside:
@vladimir-d said in LDAP not exposing outside:
Yes, this works for ldaps://<cloudron-server-domain>:636 but not for local IP ,e.g.
ldaps://192.168.10.10:636As @nebulon said, IP addresses cannot have a valid certificate. But (for whatever reason), you really want to use an IP, you can
export LDAPTLS_REQCERT=never
which disables the cert check forldapsearch
and friends.
Yes, sorted that with passing a flag to switch the cert validation off to ldapsearch.
LDAPTLS_REQCERT=never ldapsearch -v -c -x -b "ou=users,dc=cloudron" -D "cn=admin,ou=system,dc=cloudron" -W -H ldaps://192.168.10.10:636
In fact, we need to connect various services to ldap not just ldapsearch, so apparently there is only one way out - we have to use a domain name.
@girish said in LDAP not exposing outside:
@vladimir-d said in LDAP not exposing outside:
ldap://<cloudron-server-domain>:636
the above has to be
ldaps://
. Do you get the same error with that?
Yes, this works for ldaps://<cloudron-server-domain>:636
but not for local IP ,e.g.
ldaps://192.168.10.10:636
By <cloudron-server-domain>
:
# ldapsearch -v -c -x -b "ou=users,dc=cloudron" -D "cn=admin,ou=system,dc=cloudron" -W -H ldaps://<cloudron-server-domain>:636
ldap_initialize( ldaps://<cloudron-server-domain>:636/??base )
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <ou=users,dc=cloudron> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# uid-0430c072-331b-4280-8a95-e92029fd16af, users, cloudron
dn: cn=uid-0430c072-331b-4280-8a95-e92029fd16af,ou=users,dc=cloudron
objectclass: user
objectclass: inetorgperson
objectclass: person
objectcategory: person
...
By local IP:
# ldapsearch -v -c -x -b "ou=users,dc=cloudron" -D "cn=admin,ou=system,dc=cloudron" -W -H ldaps://192.168.10.10:636 "cn=uid-13f9d18f-afd2-4c41-b78d-f2a32c0a3e18,ou=users,dc=cloudron"
ldap_initialize( ldaps://192.168.10.10:636/??base )
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
Wrong cert for the local IP?
Also I noticed that if I save Directory Server
configuration several times, multiple duplicate rules added to iptables:
-A PREROUTING -p tcp -m tcp --dport 636 -j REDIRECT --to-ports 3004
-A PREROUTING -p tcp -m tcp --dport 636 -j REDIRECT --to-ports 3004
-A PREROUTING -p tcp -m tcp --dport 636 -j REDIRECT --to-ports 3004
-A PREROUTING -p tcp -m tcp --dport 636 -j REDIRECT --to-ports 3004
@girish well, telnet <cloudron-server-ip> 636
started to work today, probably another reboot helped.
Now I cannot get anything via ldapsearch
neither by a local ip nor by <cloudron-server-domain>
.
# ldapsearch -x -b "ou=users,dc=cloudron" -D "cn=admin,ou=system,dc=cloudron" -W -H ldap://<cloudron-server-domain>:636
ldap_initialize( ldap://<cloudron-server-domain>:636/??base )
Enter LDAP Password:
ldap_result: Can't contact LDAP server (-1)
Hi,
It doesn't seem that a long waited feature - the ability to expose LDAP outside is working in our environment after the recent upgrade to 7.1.3.
For some reason 636 port doesn't get available even locally.
netstat -tulpn | grep 636
shows nothing, but 3002 port is still there though.
Also wondering if there is an ability to expose LDAP to a local network only on a specific network interface, e.g. 192.168.10.0/24.