Warum ich meinen Facebook-Account nicht lösche …

Irgendwie kann ich den derzeitigen Hype um den “Daten-Skandal” bei Facebook nicht so recht nachvollziehen. Es war doch schon immer klar, dass Facebook möglichst viele Daten sammelt und diese möglichst gewinnbringend weiterverkauft. Das, und nur das, ist das Geschäftsmodell von Facebook. Jeder der einen Facebook-Account hat, sollte das eigentlich wissen und jetzt nicht plötzlich ganz schockiert sein. Auch wenn man nicht die Geschäfts- und Nutzungsbedingungen von Facebook gelesen hat, sollte das jedem klar sein. Man muss schon sehr blauäugig sein, wenn man denkt, eine Aktiengesellschaft wie Facebook macht das alles völlig kostenlos und ohne Gegenleistung der Benutzer.

(more…)

No longer possible to subscribe to new articles or comments via mail

In preparation to the new European data security law (GDPR / DSGVO), I just have disabled the possibility to subscribe to new comments to articles where you have already commented via mail. I am not willing to risk any data privacy issues because of that. So please say thank you to the European Community 🙂

As a replacement you can always subscribe to new articles or new comments via the corresponding RSS feeds.

IBM HTTP Server: Managing SSL Certificates from the command line

Sometimes one is not allowed to use graphical commands in a Linux environment so that you cannot use the “ikeyman” tool to create keyfiles for IBM HTTP Server and import SSL certificates to it. In this article I document the commands to do these tasks from the Linux command line:

Create a key file

 

List certificates in a key file

 

Import a PKCS12 certificate to a key file

 

Show the default certificate

 

Set the default certificate

 

 

 

IBM Connections CCM: Activity Stream entries are delayed

I did have the problem that if someone uploaded a file to a CCM library within a Community, the Activity Stream entries for “Recent Updates” and the users homepage did not appear immediately but appeared only the next day at 12:00 am.

The reason for that was, that someone had created schedules for the CCM Sweep Subsystem. One schedule for every day, starting at 12:00 am.

You can find that setting in the ACCE under “ICDomain -> Sweep Subsystem: Schedule”:

IBM Connections CCM: Activity Stream entries are delayed

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

After I deleted all schedules (on the screenshot you just see three entries, you need to scroll down to see all schedules that are defined!) and saved the configuration in the ACCE, all activity stream entries for that day were published immediately and now the entries appear immediately after a user uploads a files …

IBM Connections CCM – FNRCD0002E – ERROR The database vendor cannot be determined from the JNDI data source

IBM Connections Content Manager (CCM) was no longer working for a customer although everything was ok a few days ago. While starting the CCMCluster the following error occurded in SystemOut.log:

Solution:

The customer changed the Linux access rights for “/tmp” for whatever reason. The changed the owner and also removed the rights for writing for “Others”. Therefore DB2 was no longer able to write some files to “/tmp” as the user “db2inst1” has no right for writing anymore. Also the stickybit was no longer set for “/tmp”:

Rights before:

Rights after “chmod 1777 /tmp”:

Then, after restarting the whole envrionment including the DB2, everything worked again.

ICMP redirects no longer working

I do have a test LAN with its own IP range and I want to reach that test LAN from my productive LAN.

For that, I have a software router based on pfSense, which has one virtual network interface in my production LAN and one in the test LAN. On my main router I added a static route for that.

About two weeks ago, that setup suddenly did no longer work. At least from all Linux and Mac OS based machines, I was unable to reach IP addresses in the test LAN. From Windows machines this still did work.

To be able to explain it a bit better, let us assume the following IP addresses:

The message I got, if I tried to ping an address in the test LAN (e.g. from a machine with IP 10.1.1.120), was something like

So it is quite normal that the main router sends the client an ICMP redirect, because there is a more direct route to the 10.1.2.0 network via the pfSense virtual router on 10.1.1.130. So no need to go first to 10.1.1.1.

The Windows machines were still correctly responding to these ICMP redirects, the Linux and Mac OS machines did not.

I have no idea what might have changed, in either my network configuration or in Linux/Mac OS, that this no longer worked. Maybe there was some kind of patch currently delivered to Linux and Mac OS which disabled that.

However, because ICMP redirects could be a potential security whole, I decided that all machines in the production LAN should get a direct the static route to the test network. As all my devices are using DHCP to configure the network parameters automatically (also the ones which should have a fixed IP address!), I was able to just push the static route via the DHCP “classless static routing” option. So no need to configure it on every single device. This should work with most of the current devices.

The DHCP option for classless static routing is “121” and you need to use a special syntax for that:

So for the example above (class C network, network 10.1.2.0/24, address of the router 10.1.1.130) it is:

Here are the steps for DNSMASQ (the DHCP server I am using on my OpenWRT based router):

  • Edit “/etc/config/dhcp”
  • Add the following dhcp_option line to your DHCP LAN definition:

  • Restart DNSMASQ:
    /etc/init.d/dnsmasq restart

Now as soon as a device renews its DHCP configuration, it should also get a static route to the 10.1.2.0/24 network via 10.1.1.130.

Update:

If you add a “classless static routing” option, then Linux machines ignore the default gateway and only set the routes added via the classless static routing. So you need to set also the default gateway like that (default gateway is 10.1.1.1):

 

Dockingstation für iPhone und Apple Watch

Immer mehr Geräte wollen auf dem Nachttisch Platz finden. Damit das Ganze nicht in einen unordentlichen Kabelsalat ausartet, habe ich nun diese Dockingstation für iPhone und Apple Watch auf dem Nachttisch stehen:

Dockingstation für iPhone und Apple Watch

Die Dockingstation kommt mit einem 48W-Netzteil und hat zusätzlich noch 2 USB-Anschlüsse um bis zu zwei weitere Geräte zu laden. Bei mir wird z.B. noch der Kindle aufgeladen (auch wenn das nur alle paar Wochen mal nötig ist …).

Man kann die Watch zwar auch quer auf die Halterung legen. Allerdings ist der Winkel nicht steil genug, so dass die Uhr nicht in den Wecker-Modus geht. Das sollte man wissen, falls man dieses Feature benötigt. Ich selbst nutze das Feature aber nicht.

Leider wird bei der Dockingstation kein eigenes Kabel für die Apple Watch mitgeliefert, so dass man das noch zusätzlich bestellen muss. Und da ärgert mich mal wieder die Apple-Preispolitik. Für ein Lade-Kabel 35 EUR zu verlangen, ist einfach ein Witz. Leider gibt es wohl keine günstigeren Nachbauten bislang.

 

Zusätzliches Netzteil für den Macbook Pro

Mein Netzteil für das Macbook Pro ist zuhause am Schreibtisch ein wenig verbaut und es ist ziemlich mühsam, jedesmal umzustecken, wenn ich das Macbook irgendwohin mitnehme. Daher musste ein zusätzliches Netzteil her.  Da ich keine Lust hatte, über 80 EUR für ein Original-Apple-Netzteil auszugeben, habe ich nach günstigeren Alternativen gesucht.

Meine Wahl fiel auf das Salcar 60W Magsafe 2 T Form . Das Teil ist 145 gr. leicht und hat zusätzlich noch 2 USB-Ladeports mit 2 A.

Damit kann ich neben dem Macbook auch noch mein iPhone oder mein Bluetooth-Headeset laden und den UMTS-Router mit Strom versorgen, wenn ich unterwegs bin. Und ich muss dafür keinen der USB-Ports am Rechner verbraten. Die bleiben dann frei für USB-Stick und externe Platte.

Zusammen mit so einem Kombi-USB-Kabel lässt sich so ziemlich alles laden, was man so mit dabei hat.

Auch wenn noch keine Langzeiterfahrungen vorliegen, bisher eine klare Kaufempfehlung.