blog.plee.me About software, technology and random things

4Jan/180

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!

23Feb/170

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!

17Dec/160

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:

  1. 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
  2. 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
  3. Update the aptitude cache:
    # aptitude update
  4. 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
  5. Install mod_cloudflare:
    # aptitude install libapache2-mod-cloudflare
  6. 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/

2Jul/130

Access Control via Hybrid .htaccess for Both Apache HTTPd 2.2 and 2.4

Hi!

If you're running the Apache HTTPd in the versions 2.2 and 2.4 in different environments but would like to control access to certain directories (include, lib, ...) via Apache, chances are that you don't want to use one 2.2 specific file and a different one for 2.4, especially if you keep transferring and synchronizing the files between those different setups.

Between versions 2.2 and 2.4 a couple of things have changed. The perhaps most prominent change would be the one that comes with the new mod_authz_host module and deals with authorization / access control. Instead of using Order, Allow, Deny and/or Satisfy you are now advised to use the new Require directive.

So what do you do if you cannot switch every .htaccess over to the new format for reasons like the one mentioned in the beginning?

You could in fact enable the mod_access_compat module and keep rolling with the old configuration. But that would only mean procrastinating until you would finally have to deal with it anyway.

The better solution is to use configurations that are not even necessarily dependent on your Apache version (remember, you could just load the legacy compatibility module in 2.4), but in fact check for the correct module to work with. The key element to work with here is the IfModule directive.

# Apache 2.4
<IfModule mod_authz_core.c>
    Require all denied
</IfModule>

# Apache 2.2
<IfModule !mod_authz_core.c>
    Order Allow,Deny
    Deny from all
</IfModule>

As you can see, there are two checks that basically work as an "if ... else" selection. The rest should be self-explanatory.

For more information about the new way of handling access with the Apache HTTPd 2.4, please refer to the official documentation.

I hope this was of any help to you.

Thanks for reading.

10Mar/120

Restoring Syntax Highlighting to Vim

Hi!

After doing a couple of updates on my servers today, I noticed that one of them had syntax highlighting in vim disabled. I double-checked to see that it was still vim that was installed, and not vi. Indeed it was, so I tried entering a couple of vim commands in order to re-enable syntax highlighting.

A couple of minutes of trying and searching the Internet went by till I got the idea to directly compare the vim version info both on one of my servers that had it working properly and the one that didn't. It turned out that even though it was the same version number and build with the same compile time it had a certain difference: one line said "Tiny version without GUI." vs. "Huge version without GUI.". The tiny version was the one that wasn't highlighting correctly.

So I checked out what the package manager thought of this:

# yum list *vim*
[...]
Installed Packages
vim-common.i386                                   2:7.0.109-7.el5                                  installed
vim-enhanced.i386                                 2:7.0.109-7.el5                                  installed
vim-minimal.i386                                  2:7.0.109-7.el5                                  installed
Available Packages
vim-X11.i386                                      2:7.0.109-7.el5                                  base

Somehow during updating it had apparently decided to install the vim-minimal package as well. And of course it wasn't installed on the server on which vim worked as it should.

Fair enough. I thought to myself that removing should fix it, but when I tried to it said the following:

# yum remove vim-minimal
Loaded plugins: fastestmirror
Setting up Remove Process
Resolving Dependencies
--> Running transaction check
---> Package vim-minimal.i386 2:7.0.109-7.el5 set to be erased
--> Processing Dependency: vim-minimal for package: sudo
--> Running transaction check
---> Package sudo.i386 0:1.7.2p1-13.el5 set to be erased
--> Finished Dependency Resolution

Dependencies Resolved

============================================================================================================
 Package                   Arch               Version                         Repository               Size
============================================================================================================
Removing:
 vim-minimal               i386               2:7.0.109-7.el5                 installed               581 k
Removing for dependencies:
 sudo                      i386               1.7.2p1-13.el5                  installed               861 k

Transaction Summary
============================================================================================================
Remove        2 Package(s)
Reinstall     0 Package(s)
Downgrade     0 Package(s)

Is this ok [y/N]:

That was weird. It felt the need to remove sudo along with it. Of course that was not okay for me, so I tried looking for a parameter for vim in order to ignore the dependencies, but apparently there are none (any more).

The solution I found after a couple of more minutes of searching the Internet was to remove the package via the actual rpm program. But don't you need the original rpm file for vim-minimal? No, you don't!

First you have to find out the complete package name, however. That can be done like this:

# rpm -qa | grep vim-minimal
vim-minimal-7.0.109-7.el5.i386

And finally just use the following command:

# rpm -e --nodeps vim-minimal-7.0.109-7.el5.i386

whereas the last parameter is of course the proper name of the package in question. --nodeps, as you might have figured already, stands for "no dependencies" and removes the package without any questions asked.

In the end, these simple steps restored the syntax highlighting functionality for my vim.

Let's hope that after the next update it doesn't decide to go monochrome again.

Thanks for reading!

1Jan/120

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/)

2Jun/110

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 🙂

8Jun/090

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 🙂 )

   
%d bloggers like this: