sorry for being to quiet at the moment. I am currently in the process of restructuring the services of the mainframe8 network so i’m quite occupied these days.

Anyway i am searching for a network attached storage device for my home-office. I need a two-disk device that provides some reliability (RAID 1 is sufficient). The box itself should have some computing power and a bunch of access methods (SSH, FTP, Samba is a must, DLNA would be good). I have thought of the DS210+ NAS server of Synology or some device of QNAP, but i’m not sure which. Perhaps the QNAP TS-239 Pro II? What do you think?

R.I.P. www.stottmeister.com 2005-2010:

From now on there is only this blog. All queries will be redirected to here.

The team of boards.ie reset all user passwords and advises all their users to change the password on all other sites where they might have used it as well. In my opinion this is a good step but not absolutely necessary. And i tell you why: boards.ie uses an uptodate version of the bulletin board software vBulletin. That uses the MD5 algorithm to “obfuscate” the users’ password. As written earlier the MD5 algorithm is known to be unsecure and should not be used to encrypt user passwords – except it has been salted. Salting means that there is an additional “secret” (technically: an additional set of bits) used to hash the obfuscated string. This increases the so called entropy of the hashsum. And this, in return, makes it very hard to “crack” the hash using traditional methods like brute-forcing or using rainbow tables. That means it’s very hard for hackers of boards.ie to get access to other systems using the gained user data. So relax and don’t panic!

Anyway the team of boards.ie has done good resetting all the user passwords as an additional security mechanism. If you want to know more about cracking MD5 hashsums I’ll suggest you to have a look on my more in-depth articles regarding this topic:

• How to crack MD5 passwords online
• How to crack MD5 passwords with John the Ripper

[UPDATE]
The boards.ie team states on Twitter (@boards_ie) that they will not send out new passwords but require users to set a new password when the site is back up:

We are not sending out new passwords. Once the site is back, you will be invited to change your password yourself.

I guess that’s fine as well.
[/UPDATE]

[UPDATE2]
@john_ruddy has made a good point. In his opinon it might be possible that the hackers will send E-Mails to the users of boards.ie containing false instructions to set a new password or enter other sensitive data. So please be aware of phishing attacks!
[/UPDATE2]

Unauthorized Site Scripting
Unofficial Site Scripting
URL Parameter Script Insertion
Cross Site Scripting
Synthesized Scripting
Fraudulent Scripting

I think i like “Fraudulent Scripting.” Anyway, i absolutely agree to Davids conclusion to his post:

Let’s hope that ten years from now we’ll be celebrating the death, not the birth, of Cross-Site Scripting!

Exactly, Cross Site Scripting has to vanish. Keep your code clean, validate every input and adopt common security principles!

photo credit: Velo Steve

Microsoft Windows, Linux and Mac OS come with standard tools that allow file generation and manipulation. This article tells you how to use them to generate files of any length.

Generating files of any length on Windows

First open the command line interface by clicking Start > Run… and entering “cmd” (without the quotes) in the dialog form. By pressing Enter the command line interface will pop up and you can insert the following string to create a new file:

C:\>fsutil file createnew <filename> <filesize in bytes>

As you see you have to state the specific filesize in bytes! For a conversion of megabytes or kilobytes to bytes see this or this conversion tool.

For example this string creates a new file named testfile.txt sized 1 Kb located in the root directory of partition C:

C:\>fsutil file createnew C:\testfile.txt 1024

Generating files of any length on Linux

File generation with Linux is as easy as with Windows. The `dd` tool to (amongst others) create new files comes with virtually every distribution. Here is the example command, intended to be run from within a shell.

dd if=/dev/zero of=<filename> bs=<initial blocksize in bytes> count=<iterations of the blocksize>


The easiest way to create a file of specific length using `dd`is by utilizing suffixes like K (for Kilobytes) or M (for Megabytes) like this:

dd if=/dev/zero of=testfile.txt bs=1K count=1

The command above creates a file of 1KB size in the current working directory.

The man page of `dd`lists the suffixes you may utilize:

BLOCKS and BYTES may be followed by the following multiplicative suffixes: xM M, c 1, w 2, b 512, kB 1000, K 1024, MB 1000*1000, M 1024*1024, GB 1000*1000*1000, G 1024*1024*1024, and so on for T, P, E, Z, Y.

As `dd` is available for all Linux/Unix distributions this applies to Unix Systems (e.g. Solaris) as well.

Generating files of any length on Mac OS

OSX provides a shell app that’s more convenient to use than `dd`. It’s called `mkfile`. Start it by firing up a Terminal window located here:

/Applications/Utilities/Terminal.app

Like `dd` the OSX pendant `mkfile` can be used with suffixes as well. Here you can use b for Bytes, k for Kilobytes, m for Megabytes and finally g for Gigabytes. See it in action:

mkfile 1k testfile.txt

As expected this creates a 1KB sized file in the current working directory.

Conclusion

As you can see, it is really easy to create test files of virtually any length on all major plattforms like Microsoft Windows, Linux and Mac OS. Try it out!

One common method to stumble about when you’re faced with software project management is the agile management principle. Some of its well known instances are Scrum (which i use) and Extreme Programming (which i don’t). But agile management is not just about a specific implementation, its about the way we work. Jurgen Appelo of NOOP.nl embraced most of the agile paradigms and how they might influence our work into one well done presentation. Here’s the video of his talk at the Agile Eastern Europe Conference in Kiev:

The slides themself are noteworthy too. Fetch them at Slideshare:

Overall an excellent talk on the agile approach and its impact on every day work life. Definatly worth watching!

(via Projektmanagement Blog, in German)

unluckily some updates of this blogs’ software did not succeed well. So all the articles were offline for the last three days. It’s all repaired now. Sorry!

[update]
In the last days i got some mails of readers (thanks!) stating that the website loads too slow. I am aware of this issue. Mostly its because of the theme i am using. It comes bundled with a bunch of a JavaScript scripts that bloat the overall size of the pages and make the page load slowly. I have turned them off today, hoping to change for the better until i have chosen a new template – or even build my own, not just a skin for a pre-made template.
[/update]

One of the ways we identify sites to notify is by parsing source code of web pages that we crawl. For example, WordPress and other CMS applications include a generator meta tag that specifies the version number. This has proven to be tremendously helpful in our efforts to notify webmasters. So if you’re a software developer, and would like us to help you notify your users about newer versions of your software, a great way to start would be to include a generator meta tag that tells the version number of your software. If you’re a plugin or a widget developer, including a version number in the source you provide to your users is a great way to help too.

If you’re using (open-source) software that is writing a generator meta tag including its name and version into the HTML code, then you’re likely to get notifications by Google if this piece of code is outdated. I think this is a good thing and it won’t cost Google that much computing power as they are already parsing the source code of the site anyway. On the other hand i am not fond of software that is giving away too much information about itself. I am still a fan of security by obfuscation – as long as this is not the only line of defense.

photo credit: orcmid

Domains transfers are bad. Many of you may know the post “Cool URIs don’t change” by the W3C. The article comes to the following conclusion:

Keeping URIs so that they will still be around in 2, 20 or 200 or even 2000 years is clearly not as simple as it sounds. However, all over the Web, webmasters are making decisions which will make it really difficult for themselves in the future. Often, this is because they are using tools whose task is seen as to present the best site in the moment, and no one has evaluated what will happen to the links when things change. The message here is, however, that many, many things can change and your URIs can and should stay the same. They only can if you think about how you design them.

So if you’re planning to serve your site over the next 2000 years you should consider the following basics and list of 20 advices. If you follow them then your relaunch including a domain transfer should come up roses.

General advices for a technical relaunch project:

• First identify which features shall be changed during the relaunch. Implement only the absolute neccessary change requests.
• Document the internal testing phase in a system that is available to all team members (for instance backpack, wiki or bugtracker) -> avoid bugreports via E-Mail, to prevent duplicate records of bugs.
• No relaunch without a testsystem that is identical to the livesystem!
• First migrate/relaunch the testsystem and record all the steps taken, to have a plan for the migration of the livesystem later.
• Discuss bugs that reveal during the migration of the testsystem with your team, then fix them, test again and document your doings in the plan.
• During the migration of the livesystem, take the website off the web. Otherwise you may have to cope with data inconsistency.
• Plan the switch / downtime (time of migration) for nightly hours (so that less users will recognize the downtime). If you have to switch in the daytime then use the downtime as PR- or marketingevent and announce some messages or even special activities while the action lasts.
• Keep an eye on your errorlogs after the relaunch. Additionally keep in mind that you may need some extra time for fixing bugs that occur on the livesystem after the relaunch.

Domaintransfer checklist:

1. Register the new domain.
2. Verify your new domain in the Google Webmaster Tools. Insert your new sitemap (after the relaunch) there.
3. Change the configuration of web statistics / tracking software like Piwik, Mint or Google Analytis to use the new domain.
4. Generate new domain related JavaScript codes for AdSense, AdScale and other partner- or advertisingnetworks.
5. Change zones and codes of your own AdServers (when applicable) to your new domain.
6. Change domain-related extensions or plugins of your Content Management System (CMS).
7. Don’t redirect internal links to your own resources but change the whole domain / code structure. (Hint by the translator: redirects are known to be bad for the performance and overall user experience of your website)
8. Use HTTP status code 301 redirections to migrate well-known URLs of your old domain to the new one.
9. Change headers and / or bodies of E-Mail generated by scripts (server statistics, order confirmations, newsletters etc.) to use the new domain.
10. Change E-Mail accounts and footers of your company’s employees.
11. Reconfigure your Feedburner account to use the new domain.
12. Notify Google of the domain transfer at least two weeks in advance!
13. Create a new News Sitemaps for Google News.
14. Set up new company related documents like stamps, business cards, media kits, notepapers etc. to refer to the new domain.
15. Create a list with backlinks to your website. Then contact bloggers, webmasters, partner, journalists and friends to adapt the backlinks to your new domain.
16. Change backlinks from Wikipedia and other wiki systems yourself.
17. Instruct all employess of your company to change to their social networking profiles to reflect the new domain. A few examples likely to be forgotten: Facebook, Twitter, LinkedIn, Xing, MyOnID, Gravatar, Delicious, Mento, Flickr, Digg and so on.
18. Keep your old domain for at least six months and support the redirections (see rule 8).
19. Search for broken Links and fix them with tools like Xenu or the Broken Link Checker.
20. Check 404 (”Not found”) and other errors of Googles crawling process via Google Webmaster Tools daily. Fix them as soon as possible.

Did we forget something? Please comment this article and i’ll happily add your suggestions to the list.

photo credit: respres

Yes, i must confess, i am on Twitter. And i have several accounts. All in all there are three of them.

1. the main account: @stottiblog
2. one non-public account with a cool name not to mention here
3. ultimately i microblog (in cooperation) as @maschinenraum – this is the official account of the Aperto Technical Unit. The Aperto AG itself tweets as @aperto.

I invite you to follow me at @stottiblog. My publication frequency is much higher there as it is here. But i guess that’s what microblogging services such as Twitter are for. For more information about you may read this page: about.