Fix GNOME GUI Login After Upgrade to Debian 10 Buster (VirtualBox VM)
Hello!
Yesterday I upgraded my old Debian VirtualBox VM from Debian 9 stretch to Debian 10 buster.
After going through all the usual upgrade steps from the official documentation and rebooting, I found myself waiting for the GNOME user selection in order to log in. Except that it was stuck with the gray background and nothing except the mouse cursor was showing up or working.
I switched to a text-only terminal (Ctrl+Alt+F5) and logged in via command line. Looking at /var/log/syslog I found the following messages repeating over and over:
gnome-shell[1281]: Failed to set CRTC mode 1448x953: Invalid argument kernel: [ 192.917346] [drm:drm_crtc_helper_set_config [drm_kms_helper]] ERROR failed to set mode on [CRTC:29:crtc-0]
1448x953 is the resolution I am using for the VM.
This current VM was created back when Debian 7 wheezy was still current, and I knew that a more recently created VM (originally with Debian 9 stretch) was working fine after upgrading to 10, so I figured that the info about the resolution from gnome-shell might have something to do with the VM's settings.
Sure enough, I found out that there were about a handful of settings that were different, most likely because over time VirtualBox defaulted to slightly different settings depending on my hardware, the template for the OS I selected (different Debian major releases) and the VirtualBox release itself. A couple of VM starts and configuration changes later I narrowed the problem down to the following VM setting:
Display => Screen => Video Memory
I raised the original 12 MB to 16 MB and thankfully the next boot showed the GNOME login mask as per usual!
Surely this is a very edge case kind of scenario, but I am hoping that this might help you in case you come across the same problem. All the other search results I found regarding roughly the same error message in the logs were about different things.
Thanks for reading!
Using OpenVPN For All Network Traffic Except For LAN
Hi!
Recently I noticed that my Android smartphone was not able to connect to YouTube via third-party apps. I narrowed it down to the issue with it being able to resolve hostnames to the correct IPv6 addresses but not being able to connect to them (somehow the IPv6 part of my internet connection is broken. A problem for a different time).
In order to work around the problem I am using an OpenVPN connection which automatically forces all outgoing connections to use IPv4, not IPv6. The only problem was that internal LAN connections did not work any more.
In the .ovpn configuration file I am using
redirect-gateway local def1
(because it is a WiFi connection), but I was also using
redirect-gateway def1
before that, which did not make any difference in that regard.
If add a route directive like the following one after the redirect-gateway directive, you can add a route to the routing table, directing all traffic for the specified route to the WiFi connection instead of the VPN connection:
redirect-gateway local def1 route 192.168.0.0 255.255.255.0 net_gateway
You will probably have to adjust the network address and maybe even the subnet mask to match your network.
The routing table is basically a prioritized table which lets the operating system decide which network adapter it should use for a specific connection. With the above entry you add a rule with a higher priority, overriding the generic one(s) from the OpenVPN connection configuration. These ones are added because of redirect-gateway def1 and tell the operating system to send all traffic via the virtual VPN network adapter, effectively sending it all over the VPN.
If you are configuring this from the OpenVPN server side, of course you can still use these directives, but in the context of the push directive. I am not doing that, however, so I saved both directives in the client configuration.
Now I can watch / listen to YouTube videos with third-party apps AND connect to LAN devices!
I hope this was helpful to you.
Thank you for reading!
Getting a Let’s Encrypt Certificate Through DNS Challenge With Cloudflare
Hi!
A couple of days ago one of my subdomains' SSL certificates expired.
Instead of paying for a renewal, I decided to have a first look at getting a free certificate from the Let's Encrypt Certificate Authority.
The ideal way would have been to set up a mechanism that would allow for an automatic certificate renewal, so I would not have to do it myself every 3 months. That is the maximum amount of time Let's Encrypt's certificates are valid for. However, in this case this was more easily said than done. The service I intend to use the certificate with is running on a shared IP and listening on a non-standard HTTPS port because the standard ports for HTTP and HTTPS are already used for something else. This prevented me from utilizing all HTTP / HTTPS based challenges to verify the hostname ownership which is an essential part of the Let's Encrypt certificate signing process.
After some searching I found a great solution that would enable me to do a somewhat half-automated, half-manual approach:
lukas2511's dehydrated ACME client in conjunction with kappataumu's Let's Encrypt Cloudflare hook.
This Shell-based ACME client allows the user to get a Let's Encrypt certificate using the dns-01 challenge. That way, you only have to create a DNS record (containing a generated value) in order to verify your ownership of the hostname instead of uploading content to the webserver. The DNS record can be created and deleted automatically through the Cloudflare hook if that is what you are using for your DNS record management.
The instructions for both the ACME client as well as the hook are pretty straightforward, so I recommend reading those if you are interested in trying this approach.
These are the changes I made in the config file (just as an example):
- Set "http-01" as the CHALLENGETYPE (explanation below):
CHALLENGETYPE="http-01"
- Set "rsa" as the KEY_ALGO:
KEY_ALGO=rsa
- Add environment variables with config for the Cloudflare hook script at the end:
export CF_EMAIL='[email protected]' export CF_KEY='1234567890abcdef1234567890abcdef' export CF_DEBUG=true
When attempting to execute dehydrated for the first time, it asks you to accept the terms. You can do that by simply entering this command:
$ ./dehydrated --register --accept-terms
Now you might have wondered why I set the CHALLENGETYPE to "http-01" instead of "dns-01"? So that we could accept the terms without any problems; "dns-01" gave me the following error: "ERROR: Challenge type dns-01 needs a hook script for deployment... can not continue."
The command I used to generate the certificates specified the challenge type "dns-01" explicitly anyway:
$ ./dehydrated -c -d hostname.example.org -t dns-01 -k hooks/cloudflare/hook.py
The first challenge attempt failed for me, but the execution went on to retry and ultimately finished successfully.
Afterwards, you can find the certificate files in the subdirectory "certs/hostname.example.org/".
I installed and executed the software in a local Linux virtual machine without any problems and then copied the certificate files over to the destination server manually. Technically I could have just done this on the production system as well, but I did not feel like saving my Cloudflare API credentials on it. It will be interesting to see how annoying the steps are going to get after a couple of repetitions. Maybe in time some other solution will have come around.
Hopefully this was a helpful recommendation for you.
Thanks for reading!
Installing mod_cloudflare For Apache HTTPd 2.4 On Debian 8 (Jessie) Via Aptitude Repository
[Update on 2019-09-19] Warning: From Debian 9 (stretch) upwards, according to the official documentation Cloudflare has dropped support for mod_cloudflare. Instead they recommend replacing it with the new alternative: the official Apache HTTPd module mod_remoteip.
Hi!
If you are using the Cloudflare proxy functionality, you will find that your web server will end up only working with Cloudflare's IPs instead of the visitors'. After quite some time I thought that there has to be a better way to go about this, and I found mod_cloudflare, a solution officially developed by Cloudflare themselves.
When I was looking at the official Cloudflare documentation on how to install mod_cloudflare for Apache 2.4 on Debian 8 (Jessie) today, I was disappointed to find that they were only recommending manual ways: installing a .deb package or compiling the module yourself.
Luckily I found a guide on how to accomplish the installation with the standard apt-get / aptitude tool for Debian / Ubuntu.
This is how:
- Add the aptitude repository to a new sources list file, e.g. at /etc/apt/sources.list.d/cloudflare-main.list - with this content:
deb http://pkg.cloudflare.com/ jessie main
- Download the Cloudflare repository key and add it to the aptitude known keys:
# wget https://pkg.cloudflare.com/pubkey.gpg # apt-key add pubkey.gpg # rm pubkey.gpg
- Update the aptitude cache:
# aptitude update
- Look at which packages are available in the new repository:
# grep ^Package: /var/lib/apt/lists/pkg.cloudflare.com_dists_jessie_main_binary-amd64_Packages
- Install mod_cloudflare:
# aptitude install libapache2-mod-cloudflare
- Restart the Apache HTTPd service:
# service apache2 restart
Hopefully this way of installing will enable everyone to update / maintain it much more easily and with less one-time use packages installed.
Additionally, this could prove even more useful for people who want to install more Cloudflare packages.
I am confident that this method also works for Ubuntu and other versions of Debian - just replace the "jessie" part in the aptitude sources list file with your distribution major release codename (like "wheezy" for Debian 7 or "vivid" for Ubuntu 15.04).
Thanks for reading!
Original source: https://emtunc.org/blog/01/2016/installing-mod_cloudflare-ubuntu-14-04-apache-server/
Using Different Color Schemes with Vim
Hey!
If you have been using the Linux console text editor vim (or: Vi IMproved), you have probably noticed already that at times - especially in files with a large amount of comments - the default color scheme on a black background is less than ideal. Dark blue on black is pretty hard to read and can strain the eyes a lot.
So today I went out to see if somebody had come up with a solution for this particular problem. I saw people who changed console colors by exporting and overwriting certain system variables, and others who edited the default color scheme.
The simplest solution I have found to this problem is just switching the color scheme. You can do that by typing the following in the already open vim session:
:colorscheme desert
where desert is just an example for the scheme of choice. Desert - for me - has just the right color for comments: aquamarine / light blue.
If you are satisfied with the scheme and would like it to be applied each time you launch vim, you can just edit /etc/vim/vimrc (or in my case with CentOS: /etc/vimrc) and add the following line:
colorscheme desert
with desert again, of course, being the chosen color scheme. This would apply this setting automatically for each vim instance that is launched system-wide. If you do not have access to the system-wide preferences or prefer just using it for your own user account, edit the ~/.vimrc instead.
The blog entry I got this tip from (Asher's space) has further instructions on how to edit existing color schemes and even a link to a blog post that explains how to edit the dark blue color for directories in ls listings with color, but I did not feel the need to go that far. If you are interested in that topic I can only encourage you to visit the original post.
Thanks for reading!
Update (2012-01-04):
Okay, looks like pingback isn't working, so here's a direct link to the original blog post:
vi code highlighting: change the default comments color from dark blue to light blue (https://asher2003.wordpress.com/)
Detecting the Linux Distribution / Version
Hi!
Just a quick method to (roughly) detect your linux distribution and version:
$ cat /etc/issue or $ cat /etc/*release
Cheers 🙂
Compiling PHP 5 with IMAP support on SuSE / openSUSE Linux
If you get the following configure error:
configure: error: utf8_mime2text() has old signature, but U8T_CANONICAL is present. This should not happen. Check config.log for additional information.
It's probably because you're missing either the libc-client-devel package or imap-lib and imap-devel. Fire up yast and install those. You should be good to go now 🙂
(I have openSUSE 11.0 and it doesn't have the libc-client-devel package, but I read about it on another page and thought I'd add it, just to be safe 🙂 )