Kamibu

KDE 4 was released a few days ago. However, Gentoo developers have no yet included KDE 4 ebuilds to the portage tree, and thus Gentoo users have to install it by hand.

The instructions here can be followed by users of other Linux distributions too, but for example Debian users may use apt-get, which is much less error-prone.

Actually, I am going to describe the way I installed KDE 4 to my own PC, and I cannot guarantee that this is going to work for you too. You have to be sure about what you are doing, as I don’t want to be blamed if someone’s computer is harmed in any way!

What you ‘ll need
* latest version of Qt (emerge -av qt)
* latest version of cmake (emerge -av cmake)
* I had KDE 3.5 installed, but I’m not sure if you actually need it
* Strigi strigi.sourceforge.net
* Soprano framework soprano.sourceforge.net
* QImageBlitz library http://sourceforge.net/projects/qimageblitz

Start the fun!

First of all, create a folder where you will build kde4. e.g.:

mkdir ~/kde4
cd ~/kde4

Now, download all the needed files from kde.org. You can use a bash script invoking the wget command:

#!/bin/bash
 
SERVER='http://files.kde.org/stable/4.0.0/src/'
#add any other package you like
FILES=( kdelibs kdepimlibs kdebase kdebase-runtime kdebase-workspace kdebindings kdesdk kdeutils ) 
NAME_END='-4.0.0.tar.bz2'
 
for file in ${FILES[@]} 
do
    wget $SERVER$file$NAME_END &> /dev/null
    echo "Done downloading $file";
done
 
echo "Done."

write this to a file and execute it:

vi download.sh # (paste the code here)
chmod u+x download.sh
./download.sh

…or you could download them from http://www.kde.org/info/4.0.php…

I’ve included only the packages that I believe to be necessary. For a complete list enter the kde download site.

Building the packages!

Now, for every package you ‘ve downloaded, you ‘ll have to do the following: (e.g. for kdelibs)

1. Decompress the .tar.bz2 file

tar -xvjf kdelibs-4.0.0.tar.bz2

2. Make a new directory where you ”ll build the package

mkdir kdelibs-build

3. Enter the directory and create the MakeFile for the package (via the cmake command):

cd kdelibs-build
cmake ../kdelibs-4.0.0

4. Build and install the package

sudo make
sudo make install
cd ../

You could actually create a nice little script to do this for the package of your choice: pkginstall.sh

#!/bin/bash
 
PACKAGE=$1;
 
tar -xvjf $PACKAGE-4.0.0.tar.bz2
mkdir $PACKAGE-build
cd $PACKAGE-build
cmake ../$PACKAGE-4.0.0
sudo make
sudo make install
cd ../

And now for e.g. kdeutils:

./pkginstall.sh kdeutils

but I think it would be better to write every command on its own, as you may encounter various errors.

The packages are recommended to be installed in this order:
* kdelibs
* kdepimlibs
* kdebase
* kdebase-runtime
* kdebase-workspace
* kdebindings
* kdesdk
* kdeutils

and any other package after these.

Try it out!

By now, you should have build KDE 4.
To try it, execute this script: kde4.sh:

#!/bin/bash
X -ac :1 & export DISPLAY=:1
exec startkde

The first line creates a new X display – e.g. I have X on tty7, and a new X display starts on tty8
and the second starts the KDE.

If everything is ok, you are ready to use KDE 4!

Troubleshooting

First of all, the previous script for testing KDE 4, didn’t work on my PC. KDE 4 loaded OK, but just after it loaded, KDE 3 started on top of it! I had to write my own “startkde”, and thankfully it was easier than I thought: kde4.sh:

#!/bin/bash
X -ac :1 & export DISPLAY=:1
plasma
exec kwin
dolphin

Instead of calling startkde, which doesn’t work as it should, we manually start plasma (the KDE desktop), kwin (the window manager for KDE) and the dolphin file manager.

And now, KDE 4 started, but it was very KDE 3-ish. I had to go to Computer -> System Settings on the main menu, and set all options on “Appearance” from “Plastique” to “Oxygen”, the default for KDE 4 (e.g. theme).

During building KDE 4 I got errors like: Package “X” missing, so I had to install that package. Don’t hesitate, and just do it.
You’ll probably don’t face such a problem if you follow my instructions at “What you ‘ll need”.

Also, I got some errors during compiling (kdebase-4.0.0 I think), and I had to change some files. Specifically:
I got an error in two files, that QWidget::SetAccessibleName was not defined, so I had to comment out one line from them. That didn’t produce any problems, but I don’t think that it is the best solution.

I hope you won’t have any other problems. If you have any, just post a comment!

In The End

Here we come to the end of this guide, I hope you had fun!

Happy KDE 4 for everyone!

UPDATE: Added description of what each line of the bash scripts does.
UPDATE 2: KDE 4 ebuilds have been added to the portage tree, but they are masked on profile.mask and under ~x86 because they are unstable (and they are absolutely right).

It’s well known that people try to brute force SSH servers using dictionary attacks to try to guess username and password combinations. The ssh daemon does not disclose the fact that password logins are disabled and root logins are disabled most of the time, and that only simple users can login, and those only using a public/private rsa key pair. We do that, it works fine, it’s good, and secure. But we still get brute force attacks.

One of them happened yesterday. The first thing we noticed was that one of our servers was down! I tried logging in to look into what’s going on, and I couldn’t see anything weird. Everything was in perfect shape. And although Apache was running, HTTP connections timed out. I restarted Apache. No luck.

Then I noticed the netstat log:

That’s the count of active TCP/IP connections every second, during the last few hours. Interesting that at some point it grows to a few hundred. This server doesn’t get that big of a load, so we weren’t expected to handle that. And it worked as a DoS.

But what was going on? Nothing in Apache access logs, or error logs…

Apparently, it was yet another SSH dictionary attack. Christian noticed it…

Oct 21 22:23:37 Gutenberg sshd[25711]: Invalid user Rauno from 84.103.144.152
Oct 21 22:23:37 Gutenberg sshd[25721]: Invalid user Reeta from 84.103.144.152
Oct 21 22:23:38 Gutenberg sshd[25735]: Invalid user Reetta from 84.103.144.152
Oct 21 22:23:43 Gutenberg sshd[25752]: Invalid user Reija from 84.103.144.152
Oct 21 22:23:44 Gutenberg sshd[25826]: Invalid user Reijo from 84.103.144.152
Oct 21 22:23:44 Gutenberg sshd[25882]: Invalid user Reima from 84.103.144.152
Oct 21 22:23:45 Gutenberg sshd[25913]: Invalid user Reino from 84.103.144.152
Oct 21 22:23:48 Gutenberg sshd[25963]: Invalid user Reko from 84.103.144.152
Oct 21 22:23:49 Gutenberg sshd[26009]: Invalid user Reversals from 84.103.144.152
Oct 21 22:23:53 Gutenberg sshd[26053]: Invalid user Riikka from 84.103.144.152

(Actual IP addresses and server names vary)

And… the log keeps going and going for thousands of attempts, and they keep becoming more often. He probably used a fast server for that.

In either case, although we were completely secure from an SSH login perspective (even if he guessed an actual password using this method -which he wouldn’t because we use secure passwords-, he wouldn’t be able to login without an rsa key), we were vulnerable to a DoS attack. Lately we’ve been trying to become less parsimonious about security, establishing almost formal procedures to avoid XSS attacks and SQL injections, as well as other attacks. It’s about time to come up with more drastic methods for blocking DoS attackers.