avinyc

Two things, there is an issue with the docker images so they are not up to date yet, but the developers are working on a solution, see details here: https://github.com/calcom/docker/issues/347 As to the syntax error, please check your variables to make sure they are correctly added. One person had a similar issue and it was an error due to the ALLOWED_HOSTNAMES variable: https://github.com/calcom/cal.com/issues/11330 You should be able to currently install up to version 3.9.1 and make sure you have the DATABASE_DIRECT_URL variable included in your configuration.

Yeah I don't have giphy running on my instance, so I'm just taking guesses here on how to help. For the variables, all of mine are uniquely generated for each one. Use openssl rand -base64 32 to generate a key and add it under NEXTAUTH_SECRET. Use openssl rand -base64 32 to generate a key and add it under CALENDSO_ENCRYPTION_KEY. And then another 2 times for the following new ones: Use openssl rand -base64 32 to generate a key and add it under CALCOM_WEBHOOK_SECRET Use openssl rand -base64 24 to generate a key and add it under CALCOM_APP_CREDENTIAL_ENCRYPTION_KEY

Did you upgrade the giphy api to production? See instructions here: https://developers.giphy.com/docs/api If you generated the secret keys for CALENDSO_ENCRYPTION_KEY and NEXTAUTH_SECRET correctly, maybe try this section I saw in the sample template here: # - APP CREDENTIAL SYNC *********************************************************************************** # Used for self-hosters that are implementing Cal.com into their applications that already have certain integrations # Under settings/admin/apps ensure that all app secrets are set the same as the parent application # You can use: `openssl rand -base64 32` to generate one CALCOM_WEBHOOK_SECRET="" # This is the header name that will be used to verify the webhook secret. Should be in lowercase CALCOM_WEBHOOK_HEADER_NAME="calcom-webhook-secret" CALCOM_CREDENTIAL_SYNC_ENDPOINT="" # Key should match on Cal.com and your application # must be 24 bytes for AES256 encryption algorithm # You can use: `openssl rand -base64 24` to generate one CALCOM_APP_CREDENTIAL_ENCRYPTION_KEY=""

Yep, i switched back to the latest tag and no prisma errors as well with the new variable added to the template. The duplicate values in common.json are annoying in the logs, but I don't think it is causing any performance issues. Let me know if you have any difficulty getting giphy or other apps running.

I missed a note at the end of that issue, one commenter said a new variable needs to be added now: DATABASE_DIRECT_URL="postgresql://postgres:@localhost:5450/calendso" So we need to add this and keep the duplicate DATABASE_URL in our template also. Looks like this change happened 2 weeks ago, but I haven't tested to see if this allows things to run correctly after v.3.7.11.

I started experiencing issues with the database and searched for the problem. I came across this issue on github: https://github.com/calcom/docker/issues/329 The recommendation is to switch the image calcom/cal.com:latest with image: calcom/cal.com:v3.7.11 until they can figure out why the container is failing. You were right to narrow down the problem starting with version v3.7.15 and I would stick to 3.7.11 for the time being. I downgraded and zero errors in my logs now, so this should be the image to stick with while troubleshooting how to get your container running correctly.

Nope, I set up each one of them following the documentation and do not have the enterprise license. It's running self-hosted and free without any cost. The only one I couldn't set up was microsoft teams because it requires a work or school account. Here is the link to the documentation, but setting them up does not require you having a license: https://cal.com/docs/introduction/quick-start/self-hosting/install-apps My reverse proxy was set up using @SpaceInvaderOne's letsencrypt tutorial: It is now swag, but the setup should still work: The instructions have you set up a custom network for the proxy container to work properly, otherwise I don't think it will protect any of the traffic to your server. Bridge mode will work if you want to access it directly, but if you are exposing this to the world, you wouldn't want that open your server. If you haven't set up a reverse proxy, I would start there first.

I use swag (formerly LetsEncrypt) as my reverse proxy. I attached my .conf file, just need to edit the server details and everything else is pretty much default. calcom.subdomain.conf

I had to redact a lot of the fields, but this is what my calcom template looks like in unRaid:

I think docker hub isn't showing those versions is because they came out at the same time and building the containers would have been a waste. I know the latest container works for me, but again there is another component that may be the culprit here. What version of postgresql are you running? I am on 15 (specifically 15.6 according to my logs) and have not upgraded to 16 yet.

My repository is set as calcom/cal.com:latest So it's pulling the latest container from here: https://hub.docker.com/r/calcom/cal.com/tags I see the versions here don't match the date of the latest pull: https://github.com/calcom/docker/releases It's not recommended to use the latest tag but I leave it for some of my containers anyway. If I had to take guess based on the last pull it is probably the v3.7.17 image.

It's telling you there is a missing table in your database, I am guessing the db is not set up correctly or got corrupted.

I am not qualified to provide actual support, but as another user that has this working on his unraid server I am happy to share whatever I can to get more people running this container. It is a great application when working. I reached out to @Squid about why the template was removed from community apps and was told that it lacked support or project tags with applicable urls to the template. If the developers or anyone that maintains the templates wants to do that, it would return to community apps. @Tolete provided his XML template which should work for a manual install. You would need to follow the steps to add it that way and it should run. As for the prisma error, I found this link which suggests using this command in your console: npx prisma generate I don't know if you messed with the postgres settings so it might be safer to do a fresh install of a new DB. Here's a tutorial video that I used and should be enough to get it running again as long as the container install goes smoothly. Good luck!

Glad you could get it running. If you need additional variables to add, they are all listed here: https://github.com/calcom/cal.com/blob/main/.env.example I had to throw in ALLOWED_HOSTNAMES and RESERVED_SUBDOMAINS I think to get the reverse proxy working correctly. The rest of them are related to the different apps they offer. The documentation was very clear to get them installed.

Ah thank you, no worries!

Strange, I don't see it in community apps either now. I don't know what happened but the template is still listed in the link I posted previously. If you are comfortable with setting up the template manually, you can click on "Click Here To Get More Results From DockerHub" and install the official docker image and add the environment varibles yourself. I can help share details if it's helpful, but it is strange they removed it from CA for no reason.

I saw an alert in my action centre, updated the plugin to 2024.02.07.0955. Now showing as blacklisted in community apps, should I uninstall or something?

Now that I finally updated due to CA deprecating anything below 6.12, I thought I was going crazy trying to figure out how to get my dashboard to show 3 columns. It's annoying but thankfully nothing else is "wrong" with the update. I tried the browser data reset but it's still not fixing it. Will keep an eye on this until someone figures it out or a future update automatically does the trick.

No, it works the same self-hosted as if you use the free version directly on their site. Everything runs smoothly, but yes you don't get the extra features that are included with a paid license. If you want to try again, let me know what issue you are having to get it running and maybe I can help.

Following up to this, and wanted to thank Ibracorp for adding the unraid template for this software to community apps (https://github.com/ibracorp/unraid-templates/blob/master/cal.com/cal.com.xml). It works perfectly on my server after tweaking the template settings. It requires following the documentation section for certain app store installs but very straight forward to modify and run (https://cal.com/docs/introduction/quick-start/self-hosting/install-apps). Setup instructions to get it initially working are here: https://hub.docker.com/r/calcom/cal.com For reverse proxy, the ip address instead of the container name worked for me.

Understood, and I do understand the risks with auto-updating, but it wasn't a problem until it became one for me:) I will follow this advice and use a specific version tag moving forward. And I also understand there was a way to discover this change if I was properly monitoring the right places, this is a learning experience for me since I didn't even know there was a discord channel as well. I'm glad this change is happening, and no matter what LSIO could have done, someone like me would have missed it anyway. I'm just glad it was nothing serious to my server setup. Thank you for the time responding, have a good day!

Thanks for sharing the link. I wish there was a heads up or warning before this happened. I appreciate the update being automatic with the container now, but I was caught off guard with my installation upgrading by itself. I usually hold off until all my apps have been properly upgraded to support the latest version before diving in. Now I have 3 apps that are disabled because my installation jumped ahead. Again, my fault for making everything auto-update nightly, but now I will turn that off for nextcloud since it requires special attention when upgrading.

Resolved - set $upstream_app needs to match the container name (in my case bitwardenrs) and I have not been updating all the sections with each updated .conf file. The addition of the location api commands triggered the bad gateway even though others were not necessary. All now match and everything works from web, extension and app. While this is technically a vaultwarden issue, I think it would have been better placed in the swag support thread.

I'm running into a strange 502 Bad Gateway issue with the latest proxy configuration file in swag (so this may be a swag problem rather than a bitwarden docker one). Currently using the 2022-09-08 file version and made my setting changes to the newer 2023-02-13 version of bitwarden.subdomain.conf and the only new changes are the Authentik settings (which are commented out) and the following: location ~ (/bitwarden)?/api { include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; set $upstream_app bitwarden; set $upstream_port 80; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } Everything is exactly the same except for this section in both files, but running swag using this one returns a bad gateway error and my vault is blank when accessing it from the browser. Switching back to the previous conf file, everything is back to normal. Any ideas what's going or if I am missing something else to adjust elsewhere?

For focus, meet, video, and xmpp A75G repositories, I got the following error in Fix Common Problems: (jitsi/jicofo:latest) has the following comments: Latest tag no longer exists on dockerHub Additionally, this application has been blacklisted from Community Applications for that reason. I went to the docker hub for one of them and the tags have changed: https://github.com/jitsi/docker-jitsi-meet The "latest" tag is deprecated and now "stable" is the correct tag. If anyone manages to get this working, they'll need to make those changes in each of the containers. It says CA blacklisted them, so not sure if they will bring them back.