The Map Is Not The Territory

A blog by Christian Willmes.

Misleading Chromium and Google Chrome warning message for self signed SSL certificates

| categories: webdev, ubuntu, open source, server | View Comments

Since some time, I am aware of a new Chromium or Google Chrome web browser warnig message concerning not "trusted" SSL certificates for SSL secured websites.

I guess that this new warnig message is part of Google's (basicaly good) campaign to support and promote the use of SSL. Google announced this campaign under the title HTTPS Everywhere at Google I/O 2014. They are talking about things like good citizenship of the web in the context of SSL.


Screenshot of the Chromium "Privacy error" warning, shown on accessing my own server via HTTPS.

The problem with that message is, that colleagues and freinds with whom I want to share data through my server, get scared by this misleading message from Chromium and Chrome, they get back to me saying that there might be somethig not working or wrong with my server. Then I have to try to explain to people, mostly barely knowing the difference between a website and a server, about SSL certificates and HTTPS, and convince them to trust me and not that serious appearing message... This does basically only work for people I know a fair bit. Some people with whom I need to work, but not know, will most probably not trust me and are scared away by this message, if they don't know enough about the matter of SSL encrypted HTTPS. And sorry Google, this is not good.


Even more misleading message chown by Chrome/Chromium if the user proceeds through the "Advanced" option.

In my view this warning message is not just very suggestive, in a way that it compromises the trust in accessing data and web applications on my server through HTTPS, it is also wrong in the content it claims. It says that accessing my server is unsafe. Which is not the case! And anybody who thinks that is the case when using a self signed certificate, please comment to this post and educate me.

I have now issued a free SSL certificate from StartSSL for the HTTPS configuration of my webserver, to get rid of this wrong and annoying warning by Chrome/Chromium. Which I am very uncomfortable with, because I do not trust this company in any way. And why the heck should I or anyone? I do not know anything about the people behind this company. And why the heck should I care? I just want to have a minumum protection for entering passwords and data into my webapplictation by providing HTTPS connection to my server. Since the Snowden revelations it is clear that SSL can be decrypted by knowledgeable enough "agency" anyway.... None the less, I am forced to trust in some company, which sells trust (which is plain wrong on so many different levels of implementation and from so many different angles of view on that matter). And I also need to force my colleagues and friends to trust in this company, from which I got some trust... This trust I gained throgh receiving and confirming an email send to an address on my domain name. That I host my Email not on the server, the domain is registered for, and where I use that certificate, does not matter for that company to trust me... :P.

On a side note, the warnings issued by FireFox or IE are way more polite, and do not scare away people from accessing my server (using a self signed certificate), they just accept the "asumed" and way less severe risk warnigs of those browsers notifications.

Finally, I have a question to you all. Please tell me, how a Self Signed Certificate is in any way less secure, than a "certified" and "trusted" one? The connection itself is not more or less secure, its just the trust. And as said, I am not comfortable with trusting some companies who can grant (sell) trust... This trust must come from the provider of the application and maintainer of the server that is to be accessed, I think.

Have fun and a good start into 2015!


 

comments powered by Disqus

Read and Post Comments

GeoNode installation on two hard disks

| categories: webdev, ubuntu, open source, geospatial, server | View Comments

I had to install GeoNode on a server with a (small) hard disk for the OS (Ubuntu Server) + software, and a second larger hard disk volume for the data. If you install geonode from the package source via apt-get, like me, you need to adapt the data locations to use the large hard disk volume. Otherwise, the data will end up on the small hard disk, where the GeoNode application is installed by default.

Because I had some work to find the best way on configuring the system in such an environment, I thought it would be good to write it into the internet, so that other people searching for solutions can find some.

System setup

As already mentioned the server runs a Ubuntu Server 14.04 LTS OS. GeoNode is installed via package install:

$ sudo add-apt-repository ppa:geonode/testing
$ sudo apt-get update
$ sudo apt-get install geonode

The second larger hard disk is mounted into '/media/data'. The goal is to have at least the most locations, where geonode stores its data on this volume.

Solution

According to an equiry on the geonode-users email list (thanks for helpfull answers to Ariel and Matthew), the following locations store the data, and will grow big over time.

/var/www/geonode/uploaded/
/var/lib/postgresql
/usr/share/geoserver/data/
/tmp/tmocat7

In the following, a solution for each of these locations is given.

GeoNode/GeoServer data directory

$ sudo mkdir /media/data/geoserver
$ cd /media/data/geoserver
$ mkdir data
$ cd /usr/share/geoserver
$ sudo ln -s /media/data/geoserver/data/ data
$ sudo chown tomcat7:tomcat7 data -R

Upload directory

$ cd /var/www/geonode
$ sudo mv uploaded /media/data/geonode/
$ sudo ln -s /media/data/geonode/uploaded/ uploaded
$ sudo chown www-data uploaded -R

Tomcat temp (cache) dir

Tomcat will write the cached tiles of GeoNode's GeoWebCache instance, which can get very big, into the tomcat temporary folder. The path of the temporary directory is defined in an environment variable, which is configured in the tomcat init/startup script.

$ cd /etc/init.d
$ sudo nano tomcat7

Find the line

JVM_TMP=/tmp/tomcat7-$NAME-tmp

...change it to

JVM_TMP=/media/data/tmp/tomcat/$NAME-tmp

Postgresql tablespace

The hardest part of the configuration is to change the file system locations of the postgresql database and its tables. At first we create a directory for the postgresql storage.

$ vmadmin@geonode:/media/data$ mkdir postgresql
$ sudo chown postgres postgresql/ -R
$ cd postgresql/
$ mkdir data
$ sudo chown postgres data/ -R

Next we set the table spaces:

$ sudo su postgres
$ psql
CREATE TABLESPACE exthd LOCATION '/media/data/postgresql/data';

ALTER DATABASE geonode SET default_tablespace = exthd;

\connect geonode

Alter the tables that grow big to new tablespace:

ALTER TABLE documents_document SET TABLESPACE exthd;
ALTER TABLE layers_attribute SET TABLESPACE exthd;
ALTER TABLE layers_layer SET TABLESPACE exthd;
ALTER TABLE layers_layer_styles SET TABLESPACE exthd;
ALTER TABLE layers_layerfile SET TABLESPACE exthd;
ALTER TABLE layers_style SET TABLESPACE exthd;
ALTER TABLE layers_uploadsession SET TABLESPACE exthd;
ALTER TABLE maps_map SET TABLESPACE exthd;
ALTER TABLE maps_maplayer SET TABLESPACE exthd;
ALTER TABLE maps_mapsnapshot SET TABLESPACE exthd;
ALTER TABLE services_service SET TABLESPACE exthd;
ALTER TABLE services_servicelayer SET TABLESPACE exthd;
ALTER TABLE services_serviceprofilerole SET TABLESPACE exthd;
ALTER TABLE services_webserviceharvestlayersjob SET TABLESPACE exthd;
ALTER TABLE services_webserviceregistrationjob SET TABLESPACE exthd;
ALTER TABLE upload_upload SET TABLESPACE exthd;
ALTER TABLE upload_uploadfile SET TABLESPACE exthd;

The tables are pure assumption, its possible to alter the tablespace of more tables later on, if further tables proof to store much data. Thats it, so far... until now everything runs as expected on the system, and the right locations store the data. I'll keep you posted if I need to adapt anything on the system.

Have fun!


 

comments powered by Disqus

Read and Post Comments

Ubuntu standard installation /boot partition size

| categories: server, ubuntu | View Comments

This is just a short rant on the standard installation settings for Ubuntu. On a fresh ubuntu install you have the option to automatically partition your harddrive for the installation of a Ubuntu Server or Desktop installation.

Normally you would think, that there are useable best practise settings for the automatic partition. But this is not really the case for Ubuntu.

As you can see in the following listing, Ubuntu creates a 228 MB partition for grub and the linux kernel images.

christian@willmes:~$ df -h
Dateisystem Gr@@e Benutzt Verf. Verw% Einge@ngt auf
/dev/mapper/ubuntu--vg-root 98G 38G 56G 41% /
none 4,0K 0 4,0K 0% /sys/fs/cgroup
udev 5,9G 4,0K 5,9G 1% /dev
tmpfs 1,2G 848K 1,2G 1% /run
none 5,0M 0 5,0M 0% /run/lock
none 5,9G 432K 5,9G 1% /run/shm
none 100M 36K 100M 1% /run/user
/dev/sdb1 228M 209M 7,5M 97% /boot
/dev/sdc1 459G 137G 299G 32% /media/workspace

This would be totally fine, if the old images would be deleted after some time atomatically, say to hold only the last 3 working or if the partition is full, delete the oldest? But you have to take care of the deletion of old kernel images yourself. See the following listing, for the files, which got collected in my /boot partiton since the installation of my current desktop system, within ca. 4 month.

christian@willmes:/boot$ ll
insgesamt 206842
drwxr-xr-x 4 root root 2048 Sep 6 13:46 ./
drwxr-xr-x 28 root root 4096 Sep 24 09:47 ../
-rw-r--r-- 1 root root 918229 Apr 1 2013 abi-3.8.0-16-generic
-rw-r--r-- 1 root root 918328 Apr 7 22:05 abi-3.8.0-17-generic
-rw-r--r-- 1 root root 918917 Mai 1 19:00 abi-3.8.0-19-generic
-rw-r--r-- 1 root root 919001 Jun 6 23:16 abi-3.8.0-25-generic
-rw-r--r-- 1 root root 919001 Jun 18 00:09 abi-3.8.0-26-generic
-rw-r--r-- 1 root root 919493 Jul 9 02:46 abi-3.8.0-27-generic
-rw-r--r-- 1 root root 919604 Aug 13 22:10 abi-3.8.0-29-generic
-rw-r--r-- 1 root root 919661 Aug 22 23:21 abi-3.8.0-30-generic
-rw-r--r-- 1 root root 154872 Apr 1 2013 config-3.8.0-16-generic
-rw-r--r-- 1 root root 154872 Apr 7 22:05 config-3.8.0-17-generic
-rw-r--r-- 1 root root 154942 Mai 1 19:00 config-3.8.0-19-generic
-rw-r--r-- 1 root root 154943 Jun 6 23:16 config-3.8.0-25-generic
-rw-r--r-- 1 root root 154945 Jun 18 00:09 config-3.8.0-26-generic
-rw-r--r-- 1 root root 154960 Jul 9 02:46 config-3.8.0-27-generic
-rw-r--r-- 1 root root 154960 Aug 13 22:10 config-3.8.0-29-generic
-rw-r--r-- 1 root root 154960 Aug 22 23:21 config-3.8.0-30-generic
drwxr-xr-x 5 root root 1024 Sep 6 13:46 grub/
-rw-r--r-- 1 root root 16801774 Apr 6 18:11 initrd.img-3.8.0-16-generic
-rw-r--r-- 1 root root 16800381 Apr 26 09:42 initrd.img-3.8.0-17-generic
-rw-r--r-- 1 root root 16795943 Mai 3 11:01 initrd.img-3.8.0-19-generic
-rw-r--r-- 1 root root 16801073 Jun 17 08:17 initrd.img-3.8.0-25-generic
-rw-r--r-- 1 root root 16802554 Jul 5 10:46 initrd.img-3.8.0-26-generic
-rw-r--r-- 1 root root 16862724 Aug 21 10:30 initrd.img-3.8.0-27-generic
-rw-r--r-- 1 root root 16864121 Aug 30 08:56 initrd.img-3.8.0-29-generic
-rw-r--r-- 1 root root 16861214 Sep 6 13:46 initrd.img-3.8.0-30-generic
drwxr-xr-x 2 root root 12288 Apr 6 17:44 lost+found/
-rw-r--r-- 1 root root 176764 Dez 5 2012 memtest86+.bin
-rw-r--r-- 1 root root 178944 Dez 5 2012 memtest86+_multiboot.bin
-rw------- 1 root root 3059383 Apr 1 2013 System.map-3.8.0-16-generic
-rw------- 1 root root 3059783 Apr 7 22:05 System.map-3.8.0-17-generic
-rw------- 1 root root 3060094 Mai 1 19:00 System.map-3.8.0-19-generic
-rw------- 1 root root 3060761 Jun 6 23:16 System.map-3.8.0-25-generic
-rw------- 1 root root 3060957 Jun 18 00:09 System.map-3.8.0-26-generic
-rw------- 1 root root 3061544 Jul 9 02:46 System.map-3.8.0-27-generic
-rw------- 1 root root 3062491 Aug 13 22:10 System.map-3.8.0-29-generic
-rw------- 1 root root 3062704 Aug 22 23:21 System.map-3.8.0-30-generic
-rw-r--r-- 1 root root 5354016 Apr 6 17:46 vmlinuz-3.8.0-16-generic
-rw------- 1 root root 5355856 Apr 7 22:05 vmlinuz-3.8.0-17-generic
-rw------- 1 root root 5356528 Mai 1 19:00 vmlinuz-3.8.0-19-generic
-rw------- 1 root root 5357392 Jun 6 23:16 vmlinuz-3.8.0-25-generic
-rw------- 1 root root 5355920 Jun 18 00:09 vmlinuz-3.8.0-26-generic
-rw------- 1 root root 5359184 Jul 9 02:46 vmlinuz-3.8.0-27-generic
-rw------- 1 root root 5360272 Aug 13 22:10 vmlinuz-3.8.0-29-generic
-rw------- 1 root root 5361936 Aug 22 23:21 vmlinuz-3.8.0-30-generic

This deletion of old images is doable for me and maybe for the 5-10% of technically savvy computer users out there. But for the "normal" user, who just want's to do things like internet, office, multimedia or other normal stuff, this is not understandable. The result will be, that those users will not have their system up to date, the update manager won't install new kernels, because there is not enough space left. And this also prevents the update manager from updating other packeges of the system. A google search of the topic shows, that I am not the only person having this issue. So this might be something the Ubuntu dev community want's maybe to rethink for furture distributions?

Have fun!


 

comments powered by Disqus

Read and Post Comments