Cloudron Forum

After a server migration I expirienced a somehow similar behaviour. After the cloudron restored from the backup penpot OIDC didn't work.

penpot package version: 1.7.0

Frontend said: "Authentifizierungsanbieter ist nicht konfiguriert."
On the backend: "E app.http.errors - hint="restriction error", data={:type :restriction, :code :provider-not-configured, :provider :oidc, :hint "provider not configured“}"

I did the following diagnostics:

• I checked OIDC login on other apps (e.g. gitlab) -> worked as expected.
• I checked curl -v https://my.mydomain.de/.well-known/openid-configuration -> it answered correctly
• cloudron-support —troubleshoot -> said all checks [OK]
• I freshly installed another instance on the same machine but different domain. As a regression to 1.1 was no Option -> same error
• I double checked DNS entries. -> same error
• I renewed the password of the accounts setup in penpot -> same error

Now after about 24h after the restore I tried again a fresh install -> it worked
Returned to the previous instance –> It all of a sudden worked.

Solution: Time is a healer…

This is realy very astonishing and I feel lucky, but it is not very reliable and now brings up questions how to secure the designwork of me and others when working with penpot. Unfortunatly I have no time left to further investigate, but it seems that OIDC & penpot have issue after restoring of cloudron...

Main Page: https://www.nocobase.com
Git: https://github.com/nocobase/nocobase
Licence: AGPL-3.0 https://www.nocobase.com/en/agreement
Docker: Yes
Demo: https://demo.nocobase.com/new

Summary: For those that are amazed by the ease of use of baserow to build internal and public faceing apps, but wish to have a low-no-code app builder they can do a little more with. The community Edition has no constrains but the Branding and self-developed plugins should be given back to the community (pretty fair, I think). Alternative to budibase, Tooljet, bubble etc.

Not to be mixed up with nocoDB which is a database with only small application capabilities …

Alternative to:
budibase - non attractive pricing
Tooljet - non attractive pricing
bubble - closed source

As every user has to have app-user permissions to correct or delete his/her data (didn't found a workaround like in baserow) … it's getting pricey pretty fast. Or am I missing something? How do you guys give your users the option to handle their data or do you do it yourself on request?

Given that, it seems that budibase is only for big companies, that can afford to pay hundreds of EUR's per month fast, for small user groups. Unfortunately in my opinion not quite the target group of cloudron … What do you guys think?

I made some weeks ago my first no-code app with baserow and need to say I loved it. But I reached so fast the limits, that this one seems to be the natural next step. +1 for this

@BrutalBirdie While playing around to overcome this error. I found an alternative solution. It doesn't fix the collabora CODE font issue mentioned here, but makes it possible to add fonts to a Nextcloud instance hosted via cloudron.

It works with Nextclouds' ability to add fonts as remote_fonts therefore do the following:

1. Add the desired fonts at https://[YOUR.NEXTCLOUD.DOMAIN]/settings/admin/richdocuments
2. Switch to the apps-filemanager of your cloudrons Nextcloud. Create the folder ~/apps/richdocuments/settings
3. Find out in which [APP-DATA-DIRECTORY] Nextcloud saves the richdocuments-data inside the directory ~/data (e.g. appdata_ocv42l2jdx7f)
4. in the newly created folder, create a file fonts.json (so ~/apps/richdocuments/settings/fonts.json exists) with the content

{
    "kind": "fontconfiguration",
    "server": "[YOUR.NEXTCLOUD.DOMAIN]",
    "fonts": [
        {
            "uri": "https://[YOUR.NEXTCLOUD.DOMAIN]/[APP-DATA-DIRECTORY]/richdocuments/fonts/[FONTNAME-1].ttf"
        },
        {
            "uri": "https://[YOUR.NEXTCLOUD.DOMAIN]/[APP-DATA-DIRECTORY]/richdocuments/fonts/[FONTNAME-2].ttf"
        }
    ]
}

5. restart the collabora app
6. restart the Nextcloud app

Additional, remove any font added to the collabora fonts directory...

Edit: After trial and erroring even more, I found nextcloud updating the fontlist only if ~/apps/richdocuments/settings/fonts.json is again saved.

Edit-2: Unfortunatly after a collabora update nextcloud needs to be restarted again to make the font changes again available…

@nebulon maybe this might solve the issue?
cheers

@girish thanks a lot super fast response. Just installed cloudron this day with the new setup-script. For the people reading this in the future) setting the immutable bit did the trick, no installation like I supposed needed. Works like charme...

@fbartels you are right the immutability is solved by the last two lines sudo chattr -i /etc/resolv.conf && ... but with my RS 2000 G9.5 the whole resolv.conf seemed to miss when I tried dpkg-reconfigure resolvconf...therefore I simply installed it...like in the snippet...
@girish The VPS have generally AVX not enabled it's only supported by the RS line a supporter of Netcup told me... Maybe this should be mentioned on the list of cloudron providers...

@girish @jdaviescoates The fix is not for the DVD Installation, but for the "original" netcup ubuntu 22.04 minimal image Netcup provides to their users in the Netcup SCP. It makes the DVD full installation of Ubuntu obsolete (and solves the issue of the OP) and reduces the maintenance burden of Netcup RS server customers... with approval I thought of confirmation on a different system by a different user than me. Sorry for the confusion have to work on my english skills

The minimal image of ubuntu 22.04 of netcup seems to have resolvconf not installed, which seems to be a dependency for init-ubuntu.sh which is used by cloudron-setup. So it produces a error like this :

Fehler traten auf beim Bearbeiten von:^M
resolvconf^M
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)

To fix it. resolvconf needs to be installed manually with these commands.

sudo apt-get update && sudo apt-get upgrade -y
sudo apt-get install -y resolvconf
sudo chattr -i /etc/resolv.conf && \
sudo dpkg --configure resolvconf

and one can proceed happily with the installation, without needing to use the full Ubuntu DVD. Can someone approve this fix?

Exactly that was the article I was referring too. Beside oft my findings it worked for my installation like a charm.

Just stumbling upon the installation and found some minor quirks of the documentation, so I thought I leave my findings here for others:

1. the documentation says "chown -R cloudron:cloudron /media/registry-shared/" you are able to use user "yellowtent" if you don´t have user cloudron available (@girish or is this a security fail).
2. the documentation says

production:
  <<: *base

  registry:
    enabled: true
    host: <DOCKER_REGISTRY_HOST>
    ...

I found in my gitlab.yml "production: &base" and left it, like it was. When I did the change the KB article mentioned it didn't work out for me.

By the way is it possible to propose changes in the KB article like this, so the maintainers just have to accept (that might streamline the workflow a little and keep the KB articles faster up to date. Again thank you so much for your awesome work grish and johannes...really appreciating it.

@necrevistonnezr you are absolutely right. @LoudLemur as the same legislative rules already applied to the paper-based business communication for a long time before already... from the surveillance perspective you are right, but it is not the government but the business owners, that are collecting the information and need too anyway to fulfill the business. When I look from different angles on it, I even sort of can understand it.

• As a business owner it makes you safe in legal cases (HGB) or financial audits (AO, GoBD)...

• As an end-user/citizen I like the regulation because, that way it is a bit more difficult to mess around with taxes (I think taxes are fair as long as all of us pay them) and with the GDPR rules we in Europe are always able to ask for deletion, change and handing out of at least any personal information...

IMHO So there is as always a fine line between surveillance and the security/freedom we as a community deserve and rely on and in my eyes we as the technical enablers have to consult at that point wisely...

But I'm neither a judge nor a lawyer anyway

@LoudLemur in germany there is a legal requirement for almost all businesses according to different laws and regulations to archive without the user haveing the option to modify, delete…so before it get‘s in the inbox. Additionally you have to find mechanisms to not archive personal information due to regulations of the GDPR/DSGVO. Very hairy therefore a solution like mailpiler was developed…

Mailpiler is a software to archive not to backup so a different usecase

@girish First of of all, a huge thank you to all participants. This is huge step for seriuos mail providing especially in germany.... but, maybe I don't see the obvious. As it is published... am I able to install it via the appstore? Or do I have to use the cli route mentioned in vladimirs readme?

@girish Thank you so much for the quick response...I can confirm putting in https://lt.my-domain.org/6FoL0A/v2 worked perfectly. the check is added by the firefox plugin itself... cloudron is awsome, for the software and the people...

I'am struggeling with the setup of languagetool app. When I use the firefox addon (with server url https://lt.my-domain.org/secret/6FoL0A/check) to connect it throws (#1, code=0). If I use the terminal with

curl -d "language=de-DE" -d "text=a simple test" https://lt.my-domain.org/secret/6FoL0A/check

I get

<html>
<head><title>405 Not Allowed</title></head>
<body>
<center><h1>405 Not Allowed</h1></center>
<hr><center>nginx/1.18.0 (Ubuntu)</center>
</body>
</html>

even though https://lt.my-domain.org works perfectly fine...

Steps to reproduce:

1. install languagetool app in cloudron
2. setup ngrams /app/pkg/install-ngrams.sh /app/data/ngrams en de which worked flawless
3. setup env file

# Protect installation with magic/hidden URL
API_PATH_PREFIX=6FoL0A
# Activate n-gram datasets (https://docs.cloudron.io/apps/languagetool/#n-grams)
NGRAM_DATASET=("en" "de")
NGRAMS_DATASET_PATH=/app/data/ngrams

so what am I missing?

(I changed the API-Prefix for obvious reasons...)

@girish absolutly fantastic... for almaost any development a vaiable alternative to figma...you guys are awsome...

@girish I would love to have this feature as well. Especcially as without it's impossible to register the domain at https://hstspreload.org...as you said.

I'm in a struggle to make cloudron.mail even more secure and tried to set up DANE. I don't know whether this is Hosting-Provider specific (currently on Netcup). So I do have difficulties to set up a valid TLSA.

steps to reproduce:

1. Download public key via browser (store it as .pm)
2. Generate TLSA entry for let's say port 25 via ssl-tools with

• Usage: DANE-EE
• Selector: Use subject public key
• Matching Type: SHA-256 Hash
• Certificate: Content of .pem file
• Port: 25
• Protocol: tcp
• Domain: mail.<DOMAIN.TLD>

3. setup entries at netcup with the following entries

_25._tcp.mail    in  TLSA    3 1 1 <FINGERPRINT>

If I check the entries via internet.nl I'm able to get one check for DANE Existance...but it seems to be not valid...

But it seems to be even more difficult to setup DANE with the short living Let's encrypt certificates. According to internet.nl we have to republish the entry every time the certificate is renewed and the cloudron generated certificate seems to have no trust anchor TA. So we are not able to use the TA certificate in the "DANE Rollover sceme" (Current + Issuer CA "3 1 1" + "2 1 1") as second TLSA entry...

Maybe @girish or anybody else has experience in pinning the let's encrypt certificate of cloudron with a sufficient workaround?