Posts made by ccfu

@nebulon I also think plain database apps would be the way to go here. Patching the app code is complicated in this particular case, so for now I I will just go with an external database.

@nebulon I thought that might be the case.

The variable I need to change is 'sql mode' as I need to remove the only_full_group_by and STRICT_TRANS_TABLES for this particular use case.

I guess the alternative would be to use an external MYSQL database for these apps if there is no other way, but a limited configuration option would be great if doable.

@jeau
Is this after restarting the server?

@fproof
Cloudron already has a mail solution which incorporates the same or similar components.

I know there is a solved topic about this, so forgive me for bringing this up again for a specific use case.

I am well aware that all apps share the same database and that therefore variable changes in mysql are not possible for one app without impacting all other apps. However, in Cloudron installations where all of the apps need the exact same SQL mode settings (but not the standard ones) and runtime setting is not a feasible option, it would seem reasonable to enable the change on that specific server. The question is: where is the mode set for the mysql version used by the apps and can this be done at one's own risk?

@nebulon I have identified that it is an issue with multisite and the setting

define( 'DOMAIN_CURRENT_SITE', 'xxx.de' );

in the wp-config file. This does not seem to be getting updated automatically and hence the change needs to be made manually (and also in the database).

Sorry, I didn't mention that it was a mutlisite installation before because I couldn't see any reason for that to affect the smtp plugin settings.

@nebulon Thanks. I am going to try a couple of things here first and will get back to you.

@nebulon

Thanks for looking into this. The lines posted are the last two, here are also the ones that precede them:

Aug 23 12:51:03 => Changing permissions
Aug 23 12:51:03 box:settings initCache: pre-load settings
Aug 23 12:51:03 box:taskworker Starting task 1602. Logs are at /home/yellowtent/platformdata/logs/.../apptask.log
Aug 23 12:51:03 box:tasks 1602: {"percent":2,"error":null}
Aug 23 12:51:03 box:apptask xxx.de startTask installationState: pending_location_change runState: running
Aug 23 12:51:03 box:tasks 1602: {"percent":10,"message":"Cleaning up old install"}
Aug 23 12:51:03 box:shell reload spawn: /usr/bin/sudo -S /home/yellowtent/box/src/scripts/restartservice.sh nginx
Aug 23 12:51:03 => Updating db settings
Aug 23 12:51:03 box:apptask xxx.de deleting app containers (app, scheduler)
Aug 23 12:51:03 box:shell removeCollectdProfile spawn: /usr/bin/sudo -S /home/yellowtent/box/src/scripts/configurecollectd.sh remove ...
Aug 23 12:51:03 box:shell removeCollectdProfile (stdout): Restarting collectd
Aug 23 12:51:04 Success: Updated the constant 'DB_HOST' in the 'wp-config.php' file with the value 'mysql:3306'.
Aug 23 12:51:04 box:shell removeCollectdProfile (stdout): Removing collectd stats of ...
Aug 23 12:51:04 box:shell removeLogrotateConfig spawn: /usr/bin/sudo -S /home/yellowtent/box/src/scripts/configurelogrotate.sh remove ...
Aug 23 12:51:04 Success: Updated the constant 'DB_NAME' in the 'wp-config.php' file with the value 'xxx'.
Aug 23 12:51:04 Success: Updated the constant 'DB_USER' in the 'wp-config.php' file with the value 'xxx'.
Aug 23 12:51:04 Success: Updated the constant 'DB_PASSWORD' in the 'wp-config.php' file with the value 'xxx'.
Aug 23 12:51:04 => Updating redis settings
Aug 23 12:51:04 Success: Updated the constant 'WP_REDIS_HOST' in the 'wp-config.php' file with the value 'xxx'.
Aug 23 12:51:04 Success: Updated the constant 'WP_REDIS_PORT' in the 'wp-config.php' file with the value '6379'.
Aug 23 12:51:04 Success: Updated the constant 'WP_REDIS_PASSWORD' in the 'wp-config.php' file with the value 'xxx'.
Aug 23 12:51:05 => Updating domain related settings
Aug 23 12:51:05 Success: Updated the constant 'WP_HOME' in the 'wp-config.php' file with the value 'https://xxx.de'.
Aug 23 12:51:05 Success: Updated the constant 'WP_SITEURL' in the 'wp-config.php' file with the value 'https://xxx.de'.
Aug 23 12:51:06 Success: Value passed for 'siteurl' option is unchanged.
Aug 23 12:51:06 Success: Value passed for 'home' option is unchanged.
Aug 23 12:51:07 => Configuring smtp-mailer plugin
Aug 23 12:51:08 ==> Configuring smtp-mailer plugin for https://xxx.de/
Aug 23 12:51:08 Error: Site 'xxx.de/' not found. Verify `--url=<url>` matches an existing site.
Aug 23 12:51:08 Error: Site 'xxx.de/' not found. Verify `--url=<url>` matches an existing site.

Having changed the domain name the starup process fails when the SMTP Mailer tries to create settings for the new domain:

Error: Site 'xxx.xxxxxxxx.de/' not found. Verify `--url=<url>` matches an existing site

The app will start without problems if I revert to the original domain.

@marcusquinn Having used both I would tend to agree with you, but EspoCRM is costly if you need (even basic) workflow and / or invoicing. These features are included in SuiteCRM.

@jdaviescoates This is one of the problems with pre-built apps provided as packages for server platforms, and I have encountered this with other companies as well. If providers are not willing to ensure that these packages are kept up-to-date, then the benefit for the customers is minimal and sooner or later they are going to run into difficulties. It would therefore be interesting to know how easy it is to bring the pre-installed Hetzner versions up to the current versions and also generally what their policy is on keeping these packages updated.

@nebulon Thanks. I did search but must have overlooked this.

Has anybody else experienced the problem with 3.6.5 that reboot doesn't work from notifications / the system info page. The notification disappears but the system does not reboot. Tried with three separate Cloudrons.

@girish Embarassingly it appears ther script that I was loading the php info through had specifically set opcache.enable to Off at runtime. In the app itself it is enables and all is good. Thanks again and apologies for the unnecessary effort in pushing a new package.

@girish Thanks for looking into this. With the new package opcache.enable_cli is now ON which was OFF before, otherwise no change as far as I can tell.

I can, however, confirm that in a fresh install opcache.enable is ON as in your screenshot and indeed other sites installed in a LAMP app also show that opcache.enable is ON. I am now wondering whether the fact that the webroot in this instance has been changed in the apache.conf to a folder immediately below /app/data/public is the reason. I can't see why it should be, but that's the only thing I can think of right now. When I have time later I will install a new instance and see whether I can identify this or something else as the cause.

@girish It's there now. Thank you!

The package update 1.7.10 from yesterday doesn't seem to be being pushed to servers. A manual search for updates also shows no update available.

I am trying to enable opcache in a LAMP app. The master value in the php info shows that opcache.enable is On but the local value is Off and adding opcache.enable=1 to php.ini does not seem to do anything.

I am sure this is quite trivial and I am almost certainly overlooking something here, but I just can't work it out. Anybody able to point me in the right direction here?

@nebulon Whilst I like the fact that read notifications are now kept, at some stage this list is going to get very long, so maybe a toggle to show unread / read notifications? And maybe also a purge function to remove older ones?

@girish

Sounds good

@girish said in Can't discard spam messages on arrival using Sieve filters:

so I think the default behavior is good.

As a default I think so too, but whilst the spam protection in Cloudron is reliable, sometimes the end user wants / needs to be able to filter spam messages directly It would therefore be good to have a simple way of filtering mails to discard spam selectively rather than just having all SPAM go to the SPAM folder. Mails with a SPAMASSASSIN score of over 20, for example, do not need to be saved anywhere, but those with a score of 7 or 8 could in theory be false positives so would warrant 'quarantining' rather than discarding altogether. The same applies to certain sender addresses and subjects.

This does not need to be something defined in webmail clients per domain, but could be a server-wide setting similar to the custom spamassassin rules.

@robi said in Can't discard spam messages on arrival using Sieve filters:

does Sieve only work on inbox?

From what I have observed it looks like this could indeed be the reason.

@d19dotca I tried to set up something similar with filters on Rainloop and can confirm that it does not work as intended - the mails that should be discarded are still delievered to the SPAM folder.

@d19dotca said in Is it possible to migrate just emails?:

Reason I'm asking is that my understanding is you can't really split roles up between servers for the same domain. In other words, it's not really feasible to have one Cloudron server hosting the website for example.com and another Cloudron server hosting the mail for example.com. My understanding is that everything related to the domain needs to be handled on each server.

Out of interest, why would it not be feasible to split domains between hosting and email? We do this without any problems. On the servers hosting the apps either outbound mail is set to relay via the server handling email or, if the app manages its own email settings, these are set to use the SMTP on the server handling email for the domain.

@nebulon Instead of a label, maybe having a coloured dot in the corner of the tile would be a good alternative for immediate recognition of the current state of the app?

@jagan

1. Set up a subdirectory for the backups in the storage box (example: cloudronbackups).
2. Create the subdirectory (example: /mnt/hetznerbackups) on the Cloudron server.
3. Create the CIFS mount:

mount.cifs //uXXXXXX.your-storagebox.de/backup/cloudronbackups /mnt/hetznerbackups -o uid=yellowtent,gid=yellowtent,user=uXXXXXX,pass=XXXXXXXXXXXXXX,iocharset=utf8 0 0

(obviosuly replacing the XXXXXXX with your username and password)

4. Choose CIFS Mount in the backup settings and set it to the subdirectory you created.
5. If everything is working, add the following line to /etc/fstab:

//uXXXXXX.your-storagebox.de/backup/cloudronbackups /mnt/hetznerbackups cifs  uid=yellowtent,gid=yellowtent,user=uXXXXXX,pass=XXXXXXXXXXXXXX,iocharset=utf8,x-systemd.automount  0  0

@jagan Is there a reason you want it to be S3 based?

We use Hetzner Storage Boxes via CIFS. Has been very reliable so far.

@subtlecourage

It's very simple. Just spin up a LAMP app with something.mydomain.com as the location. Then, in the file manager create a file .htaccess in the public directory with the following content:

# Permanent URL redirect 
RewriteEngine on
Redirect 301 / https://externaldomain.com/path

Any requests to something.mydomain.com will then be forwarded to externaldomain.com/path

There is plenty of documentaton on this if you do a Google search for 301 redirect .htaccess. there are also generators that will provide you with the correct code for different scenarios, for example redirecting specific pages.

Why not use a LAMP app and .htaccess?

@marcusquinn I meant to reply to this ages ago. I have also started using Espocrm and am also considering moving email communication from Freescout to Espo so that everything is in one place. What is missing for me in Espo, however, is reply snippets that can be inserted into emails. I know that you can use templates, but you can only use these to replace an entire email.

@girish Thanks for that command. It is indeed strange and I haven't seen it on other Cloudrons, so something must have got stuck with this one. Not a big deal, but it's nice to have that message not displaying any more.

@girish Yes, that is the expected behaviour but the message in the logs is from the install date in March and the server has been rebooted several time since then (for example to finish security updates) and has also seen updates to 6.2.7 and 6.28. The message is still there.

I just logged in to a server via SSH that has been running well for a couple of months and noticed the following message:

Cloudron is installing. Run 'tail -f /var/log/cloudron-setup.log' to view progress

The log shows as the last entry:

start: Almost done

How can I remove the 'Cloudron is installing' message?

@andxclfor IP reputation is becoming increasingly important for mail delivery and both T-Online and Microsoft have implemented quite aggressive checks. If your domain starts sending mail from a new IP, for example, there is a good chance it will initially be blocked. You should get an undeliverable error in such cases though. From experience I can say that T-Online have been very quick to rectify this.

@nebulon My understanding is that the referrer is not sent when same-origin is set.

Here is the link I was referring to: https://github.com/getkirby/kirby/issues/3257

There may of course be a better way and ideally the header should not be set universally.

@nebulon

Thanks for the input. I also suspected CSP but the videos load when the domain restriction is turned off so I think it is more likely to be because of the referrer-policy "same-origin". I eventually found a post on the Internet which suggested setting "strict-origin-when-cross-origin" in .htaccess, but this doesn't seem to have any effect as the page is still showing "same-origin" in Inspector. Or does this have to go in the apache.conf and then restart the app to work with Cloudron? I am now wondering whether the Wordpress installation is overriding the header setting in .htaccess so will check that too.

Edit: It seems that the App is somehow overriding any attempt to change the referrer policy. Could that be? I added the referrer policy to the header in Wordpress and also tried via a plugin and it is still not changing what is sent to the browser.

I have just moved a Wordpress website from a different server on to a Cloudron using the LAMP App. The site includes a number of embeded Vimeo videos which are protected using domain restriction. On the old server they worked fine, on the Cloudron server the videos will not play 'because of the domain restriction settings'. If I remove the restriction they play fine and I cannot work out why this should be happening.

Does Vimeo perhaps check for something else besides the domain name? I can't find any information that would suggest this to be the case. I am thinking it could just be a DNS issue which will resolve itself after a while, but if it is not, does the LAMP App block any referer information that might be the cause?

Any help or suggestions would be greatly appreciated.

@girish Actually I think this is correct as it is because it says setup A records for [domain] and not set the A record to [DNS entry]. To be 100% correct it should in fact say Set A records for [domain] to this server's IP though

@p44 @jdaviescoates Got it working. Thanks for your help!

@jdaviescoates @p44
Many thanks. I'll look at this again later today and report back.

@p44 The Storage Box is in Falkenstein. The Cloudrons I am attempting to set this up with are also both with Hetzner, one in Falkenstein, the other in Nuremberg.

@p44 Did you get the issue sorted with the Hetzner Storage Box? I am facing the same problem and cannot work out why it is not mounting. "Samba Shares" and "External Reachability" are enabled but I keep getting the error 'mount: bad usage'.

@nebulon Fantastic, thank you!

@nebulon Thank you. Yes, that makes sense. Hope this can be resolved as having IPv6 as a source IP is not uncommon.

@nebulon It fails with just one range being added and nothing else in the input field. I tried different browsers and checked for special characters. Without the ranges all is fine.

I am not really sure what the error message is trying to tell me to be honest as these are all IPv4.

+1 for Canvas LMS on Cloudron

@girish Adding the individual IPs seems to work fine, but as soon as I try to add a range I get the error. This is odd though because these ranges and a few individual IPs were already in the list. The errors seem to have started occuring after the latest update to 6.2.7.

@girish As they are all either on blocklists or publically listed:

5.188.206.246
74.120.14.0/24
162.142.125.0/24
167.248.133.0/24
192.35.168.0/23
77.247.110.129
45.144.225.181
71.6.232.4

@girish Yes in the dashboard. Here is a screenshot:

@blaise Not a great start to your membership here in the forum. The response may not have answered your question exactly but that hardly justifies your impolite reaction.

Incidentally, a simple Google search would have found you this:

https://docs.rocket.chat/installation/hardware-requirements

A bit of multiplication and you should have a reasonable idea what you are likely to need.

Edit: I see @fbartels was a bit quicker.

This seems to have nothing to do with the comments after all. The error appears randomly when attempting to add new Ips or ranges (all IPv4) but there is no apparent logic to it.

When attempting to add comments to the blocked IP ranges in the firewall configuration (on separate lines as per the docs) I am getting the error ipaddr: cannot match ipv6 address with non-ipv6 one. Is it no longer possible to add comments or is this a bug? What does this error actually mean here?

Does anybody know whether there a way to set the Haraka mailserver in Cloudron to BCC all outging mail from a certain email address to another address (on the same domain, primarily for archiving purposes in an IMAP mailbox). I know Postfix has a feature to do this.

@p44 That is be the expected behaviour. As there was no 2am this morning the backup was not triggered.

@d19dotca @martin I currently have three Cloudrons, two showing update available to 6.2.6 and one showing 6.2.5. It doesn't seem to be possible to recheck manually once update available is shown in place of the check update button on the settings page.

@grienauer Why do you find this misleading? The function is password recovery so it seems logical to me for the title to be 'change password recovery email address'.