I’ve written about this issue before, in 2008. But as it turns out, the problem still exists with todays version of the Citrix client, version 12.0, now called Citrix Receiver. And people are still searching for an answer on how to solve this issue.
You have not chosen to trust [certificate] the issuer of the server’s security certificate (SSL error 61)
Both the problem and the solution is the same as before, only the name and the path is different. The path depends on whether you installed the client/receiver as a normal user, or root, also known as the superuser.
I’ve used Ubuntu 11.04 here, but I reckon it’ll work on any Linux distribution.
The problem is this; When you install the Citrix Receiver, it will only install a handful of certificate files, and we’ll have to provide the rest. Now, where can we find a reliable source of SSL certificates? Well, it turns out that we most likely have that already. The same source our browser is using.
Just copy those .crt files over to the Citrix keystore, and we should be done. If the client is installed under /opt/Citrix/ICAClient/, run this command in a terminal:
For the last few days I’ve been fighting TweetDeck on my laptop trying to get it to open web pages in Opera. A small, but fast browser, from the Norwegian company with the same name.
At first I thought that Opera wasn’t my default browser in Gnome. I’m currently using Linux Mint, a distribution based on Ubuntu. So I checked the “Preferences->Preferred Applications” and made sure Opera was the default application for browsing the web. I also checked with “gconf-editor” just to be safe that Opera was set as default browser.
Having checked all this. I did a few tests and found out that Opera was indeed the default application for surfing the web. So the problem had to be limited to TweetDeck or Adobe AIR.
Now. I checked all the xml-files regarding Adobe AIR and TweetDeck, I even installed SQLite3 to read the database file for TweetDeck in my home directory. No luck.
But the Internet is a collection of tubes amazing and brilliant people. So I searched and found Andrea Olivato, which in turned had found the solution to my (and many others) problem. He discovered that Adobe AIR has hard-coded firefox as default browser in libCore.so, which (usually) can be found in /opt/Adobe AIR/Versions/1.0.
His solution to the problem was to open libCore.so with vim, or any other editor for that matter, and search for the word “firefox”. Ok, he writes that he jumps directly to line 15500, but this might change. But then again, maybe Adobe will make it work in the future. Anyway. He replaced “firefox” with “browser”, which is the same length. Very important. And created a symlink from his favourite browser to, well, browser.
In my case:
ln -s /usr/bin/opera /usr/local/browser
I noticed that in libCore.so, Adobe has a reference to /desktop/gnome/url-handlers/http/command, which is the registry setting for Gnome when it comes to default browser. Why this isn’t used I don’t understand. Perhaps the hard-coded firefox is a backup solution in case AIR fails to retrieve the information from the registry.
This weekend I decided to finally upgrade the firmware on my Linksys WRT54GL wireless router. The whole reason I bought this router a few years back was because it supported third-party firmware based on Linux.
Up until now, Linksys firmware has been working great. I didn’t need more than a simple wireless router. But recently I’ve started playing with VMware ESXi, which led to a few virtual servers. And with a few virtual servers, there was also a need to make them accessible from the Internet. With the only way of opening up ports on my router was through my ISPs web page, and that every change needed to be accompanied by a reboot of my router, I decided it was time to set up my own firewall.
Support for VLANs
OpenWRT support VLANs, and this is one of the main reasons I wanted to upgrade to a third-party firmware. Running a firewall with just one network adapter isn’t really possible, unless you can split networks within the same physical medium. And that’s when VLANs come in to the picture. This technology makes it possible to have several different networks within the same physical medium. Even the with the same network addresses.
The firewall, which is a virtual machine, doesn’t know that the host it’s running on only has one network adapter. I gave the firewall three adapters, all connected to different virtual switches. These switches tag their traffic with VLAN data and sends it to my Linksys router, which in also was configured the same way. One port on the router could hand out data for VLAN1, the next port for VLAN2.
In my setup, the traffic coming from Internet is connected to a port in VLAN2. This is sent, along with data in VLAN3, via port 4 to the ESXi host. Here the traffic is divided into virtual switches. One switch for each VLAN. So my firewall is connected to both the switch for VLAN2, and for VLAN3. VLAN2 is being labeled as WAN, while VLAN3 is labeled LAN. I also have a VLAN4 named SERVERS.
This is easy. If you haven’t installed a third-party firmware on your Linksys, you can use the web interface from Linksys to upgrade. Just as you would if you were to upgrade the original firmware. Download the correct image from OpenWRT, select it in the web interface and click the upgrade button.
After the new firmware is installed, the router will reboot and ready for configuration. By default the routers IP-address is 192.168.1.1. You can log in via telnet with no user name and password. It is advised to set a password at first log in. Doing so, telnet will be disabled and ssh enabled instead.
If you manage to lock yourself out, it’s possible to restart OpenWRT into a safe mode. Just take the power, when it starts up, press any button just when the DMZ light is lid. Now you can access it via telnet at address 192.168.1.1 again, no matter what address you have specified earlier. In safe mode you can change password and reconfigure firewall rules, if you have enabled a rule you shouldn’t have.
Setting up different VLANs (and trunking them)
First you should be aware of how the WRT54GL hardware is mapped internally. It is essential to understand the logic when configuring the router. The image shows the default configuration where port 1 – 4 is a regular switch on VLAN0, and the WAN port is separated on VLAN1. If you only want a dumb switch with 5 ports, you could put the WAN port into VLAN0 as well.
The configuration file can be found under /etc/config/network. Here we can set the IP-address of the box, but also configure the ports. I only need a dumb switch with VLAN capabilities, so I won’t set up any fancy routing rules in this post.
In this setup I have created five VLANs, three of which are unused at the moment. VLAN3 is the default VLAN, as marked by the asterisk (*). Port 5, the internal, has to be included. Data on LAN port 4 (which is internally mapped as port 0), is tagged, which basically means it’s a trunk. If a port isn’t tagged, it can’t belong to more than one VLAN (except the internal port 5). If a port is tagged, it can’t be used by a computer which doesn’t support trunk or tagging.
My Internet connection is connected to the WAN-port on the router, also known as internal port 4. It belongs to VLAN2, and is tagged on LAN port 4, which is known as internal port 0. On the other side of LAN port 4 is my ESXi server, which supports trunking (surprise). VLAN2 then goes into my firewall, on the other side of my firewall is VLAN3, which goes over the same cable back to the OpenWRT box, which in turn distributes it to my main computer and media center on LAN port 1 and 2.
Linksys WRT54GL is a great product, and with third-party firmware such as OpenWRT, it’s even greater. This box can be transformed from a boring wireless router, to a full blown firewall if needed.
However, be prepared to answer some questions regarding different configuration files. More specifically if you want to keep the original, or overwrite with a new one. I myself have edited a quite a few configuration files over the last year, so I had to do a manual screening before I decided what to do.
Today I had a case where a server mounted the root filesystem as read-only during boot. To make a short story shorter, check /dev/null.
After doing some searching in the logs I found a few lines complaining about /dev/null also being read-only filesystem. So I checked the permission with ls -al /dev/null, and it turned out this had been changed into a regular file rather then the special file it’s supposed to be.
The fix is easy. Delete the file called /dev/null and re-create the special device with the command mknod -m 666 /dev/null c 1 3.
You can also read about how to create this special file by reading the man-pages. Command: man 4 null.