Isn't the intent of livepatch to minimize reboots?

@Robin If you delete the dashboard nginx config with the name my.xx.conf in /home/yellowtent/platformdata/nginx/applications and then systemctl restart box, it should fix things up.

@plusone-nick right, the email just contains a URL for the image and the URL does not change on image change.

There used to be a limit of domains/uses etc but we removed all limits in the previous release.

@nebulon Thanks a lot for the info. I'm going to try it out when I have some spare hours left this week.

I'll report back.....

This is fixed in https://git.cloudron.io/cloudron/dashboard/-/commit/b3cdcb2adb4666f274ed23f2ab05428563531dc8

@girish Hmm, that didn't match the behaviour I saw. I ended up with two separate SPF records in Hetzner. One that I had already set up from my own DNS setup, and one added from Cloudron - which didn't contain the content of my own record. Thankfully it wasn't difficult to fix, once I read up on it.

@imc67 Fair enough, I have made it unsolved. I have reworked large portions of the certificate logic upcoming release, so this should definitely got solved soonish.

I think the main thing is you are looking for subscribe/unsubscribe like mailmain, then Cloudron does not have that feature.

Just to close this topic up. It seems one mayor factor seems to have been that the "worker" in authentik was stuck and therefore did not attempt to connect to process the ldap connection. After it started processing the connection it ran into some python tracebacks because of missing attributes. I could not get the sync to run, but then anyways decided to do it the other way around and use authentik as my primary source of users and connect my Cloudron to authentik instead.

The final switch is still pending however as Cloudron already has an ldap source configured, which I am going to decommission soon.

@nebulon Issues solved it was my issues by doing wrong LDAP Filter.

@ajtatum Congrats on the success and all the learning! 😎

@girish said in Adding a new user with _ in their username doesn't work and generates no errors/ warnings/ messages:

I tried this now and see a message:

guess you must be running a patched/ fixed version?

Are you using the external storage plugin in Nextcloud itself or have you moved the data location of your app instance via Cloudron dashboard?

Also can you be a bit more specific about the actual behavior you were describing? Do you end up with copies of the data on two disks or something like this?

@nebulon can you maybe have a look into the other thread, I am a bit stuck but it would be important to get this right for a porject of mine.

@savity So, create a file named /etc/systemd/system/docker.service.d/custom.conf:

[Service] ExecStart= ExecStart=/usr/bin/dockerd -H fd:// --log-driver=journald --exec-opt native.cgroupdriver=cgroupfs --storage-driver=overlay2 --experimental --ip6tables --bip 192.168.1.1/24

Then,

# systemctl daemon-reload # systemctl restart box

If you do, docker network inspect bridge, you will see the IP has changed.

@roofboard
Hmmm I am looking at Rclone It appears to be the backend that many file sync apps like google drive use to "do the magic"

This may be a part of the better solution for folder synchronization...

@girish done

@girish We did. We also had a RAID1 configuration which is why it probably why the server didn't go down all together. I was just surprised that the NVMe memory got corrupted within 6 months of having this server which is why I didn't suspect it until they ran the bench test.

@girish
Screenshot_20220806-154525_Samsung Internet.jpg
I had same issues... is there way Workaround?
Edited -
I just read your comment you work on it. Thank you for all your guy work

@jdaviescoates said in dynamic ip - TTL/manual update?:

Never really got why so many people use Cloudflare, mostly seems to just add complications and break things, and contributes to massive centralisation of the internet

I'm using their DNS proxying to hide my home server IP address. I don't know of any alternatives. Especially one that has DNS proxying AND is already added to Cloudron (for automating DNS).

As @jdaviescoates said, we force small case for compatibility. I understand that in your specific context that being case sensitive might work though.

LDAP itself has a bunch of case sensitivity madness. See https://stackoverflow.com/questions/29897684/is-ldap-dn-case-insensitive and https://www.ibm.com/docs/en/oala/1.3.5?topic=SSPFMY_1.3.5/com.ibm.scala.doc/install/iwa_pinst_ldap_cnf_cse_sen_t.html . I remember we tried to make this case preserving but this causes lots of subtle very hard to debug failures.

There's a lot of things in play here 🙂 File systems, databases, frameworks, languages... each has their own level of case sensitivity support when it comes to usernames.

@erronnie Would also be interested in this - in particular if you can still manage mails with your own domain in that setup….

Problem solved. I deleted ALL config files and restarted the server.

@qilin said in New to Cloudron. Having different issues:

The strange part is that there are no bans which is worrisome to me.

So, this doesn't work most because fail2ban itself works by scanning log files and as you said, there is nothing in the auth.log.

Generally, this is outside Cloudron configuration (as in, Cloudron does not configure or update all this on the server). My understanding is sshd logs always to syslog. You can check the Facility with which it logs in /etc/ssh/sshd_config. I think from there it goes to /etc/rsyslog.d/* config files to log based on the facility. Not 100% sure, maybe others can chime in.

@girish I did something slightly different (but maybe not SO uncommon). I created the server and put the clients domain into my own (developer) cloudflare account. After everything worked I created the domain in the client's cloudflare account and changed the NS entries (basically this: https://developers.cloudflare.com/fundamentals/get-started/basic-tasks/manage-domains/move-domain/).

the situation was now, that the API key was still valid but changed the wrong domain entries at cloudflare. so, I imagine cloudron creates the NS entry, checks if this works (which it doesn't) -> brain freeze. Something like this?

@humptydumpty

I am not sure about windows since I use Linux but I tried to search a little for an answer. It seems to be related to HTML5 canvasing.

Maybe you can try this on FF:

Mozilla Support: Firefox protection against fingerprinting

@humptydumpty done