Run the following to open the editor for
sudoedit /etc/apt/sources.list
And comment out the first line by adding #
to the beginning
Problem solved!
Run the following to open the editor for
sudoedit /etc/apt/sources.list
And comment out the first line by adding #
to the beginning
Problem solved!
This guide talks about setting your enterprise Keycloak as a way your employee can log into their Google Workspace.
Most of the guides online talk about how to use Google as an identity provider for KeyCloak. The only one I found about using Keycloak as identity provider to Google was outdated and did not work. So I wrote this article.
First, create a new SAML application using the following config:
Remember to replace example.com
with your Keycloak domain.
Now, Google requires an email mapping. This means, if you have an account in Google Workspace with email [email protected]
, you will set the email property of that user in Keycloak to be [email protected]
and set the below SAML capabilities / Name ID format to email
.
The rest of the configuration can stay untouched.
After creating the application, open it, and go to the Keys tab to copy the certificate to a new file called saml_pub_cert.pem
Now, in the file, make sure you include --—BEGIN CERTIFICATE-----
in the beginning and --—END CERTIFICATE-----
at the end of the line. Like this:
Go to your Google admin portal. And go to the Security >
SSO with third-party IDPs.
On the tap, tap to create a profile in the Third-party SSO profile for your organization
section:
For the certificate file, upload your saml_pub_crt.pem
Save the changes.
Now, access this URL:
https://your_keycloak_domain.example.com/realms/your_realm/protocol/saml/clients/googleapps?RelayState=true
And you should be able to login.
There might be an issue where after logging in, it shows this page:
While I have not figured how to solve this yet. You are already logged in. You can navigate to google.com
or gmail and you will see that you have logged in via Keycloak identity.
In the newest Mastodon V4.3.0, you only need to modify one file in order for the maximum character count to be changed.
If you search for the max_characters
keyword in the Mastodon Github repository, you will see that it all points to the value within the StatusLengthValidator
and a variable called MAX_CHARS
To modify it, first, ssh into your Mastodon server, and switch to the root shell:
sudo -s
Then, switch to the Mastodon user
su - mastodon
Now, modify the validator file:
nano -w live/app/validators/status_length_validator.rb
At the very top of the file, you will see the MAX_CHARS
variable, which was by default 500, you can modify it to another integer, for example 3000 to allow a maximum of 3000 characters within each post.
# frozen_string_literal: true
class StatusLengthValidator < ActiveModel::Validator
MAX_CHARS = 3000
URL_PLACEHOLDER_CHARS = 23
URL_PLACEHOLDER = 'x' * 23
That’s how you do it! Now, exit to root shell and restart the Mastodon processes, or simply reboot.
mastodon@Mastodon:~$ exit
logout
root@Mastodon:/home/ubuntu# systemctl restart mastodon*
root@Mastodon:/home/ubuntu#
You can read the custom character count from the /api/v1/instance
endpoint, and find the character count in the Root/configuration/statuses/max_chatacters as an integer.
As I am working on a brand new Discord-styled modern Matrix client, I went into an issue: because I use the newest Matrix Rust SDK, it requires Sliding Sync (as does the new Element X app). So my self-hosted test Matrix server no longer works.
I could not find any guides on how to set this up. So I am writing it here on how I did it by referencing the official documentation:
Remember to modify `SYNCV3_SERVER` to be your own instance’s hostname
Generate a secret code:
Start docker:
If you use Nginx for forwarding requests, you should add the below in your existing Nginx configuration file:
By the way, here is an example Nginx file for a Matrix instance:
It should look like this, but with all hostname replaced:
If your sliding sync proxy `org.matrix.msc3575.proxy` runs on the same server, set it to be the same as your `m.homeserver`
If you’re hosting your website on CloudFlare, you should use a CloudFlare worker to respond the well known file:
If you’re using Nginx, you should provide a custom well known file, and write the rule to read all well known requests from your given path.
Here is the example content of the client
file located at `/var/www/html/.well-known/matrix/client`
Here is the example content of the server
file located at `/var/www/html/.well-known/matrix/server`
Don’t forget to apply the updated configuration file: