First steps

First, I only had problems. I had a problem connecting to the webinterface, because the manual mentions the wrong default user/pass pair for logon. Sick. By the way, this is the same manual that says that SNMP is the standard internet mail transfer protocol. Fsck it. I usually read manuals – but this one is just able to heat the air when you finally burn it. Maybe not even that.

Then, after finally logging in, I found this buggy, ugly and crappy webinterface. What a user expirience. Shit. At least it works to make the basic settings.

The AP finally worked for my wireless devices.

And then tests. Well, the firmware is not even able to do station monitoring or some other basic stuff. Argh.

The solution to all the problems and crap

DD-WRT… Flashed the thing (okay, I bricked it on the first try, my fault), booted, logged into the nice and usable webinterface, made the basic configuration, ready. I have shell access, basic tools, a Cron, remote syslogging and some more features (a rich featureset, compared to the original code image).

If you are able to put something like OpenWRT or DD-WRT on your lower priced Linksys devices: Do it.

Rant to Cisco

Are you really sure you want to put your Logo on this device? The original firmware sucks and the manual is written by idiots. Nothing I usually have in mind when I hear “Cisco Systems”. I’m aware that this is consumer hardware, but a bare minimum of quality should be there. For me, Cisco stands for high performance, reliability, quality – this thing, that carries a Cisco logo, is just a shadow of the functionality and quality of a Cisco console cable!

Also: On the internet I read in far too many forums that the technical support from Linksys is as good as no technical support. I’m glad that I didn’t need it.

• GNU Batch (ehem. XI Batch)
• SOS Scheduler

GNU Batch

GNU Batch ist eigentlich ein uraltes Produkt (Anfang der 90er) das zwischenzeitlich nur den Namen gewechselt hat und bei der Versionierung wieder bei 1 angefangen hat.

PRO

• stabiler Kern
• Prinzip Multiprozess + SHM
• portabel – “could go mostly wherever Unix went” (C/GNU Autotools, GTK+, Motif)
• Globale (Scheduler-weit oder Cluster-weit), atomar nutzbare Variablen (geeignet zum Chaining und als “Job-IPC”)
• saubere Dokumentation über Recoverymöglichkeiten des Scheduler-Status beim Crash (Auslesen des SHM Segmentes, etc.)
• saubere Dokumentation des C-API (und sauberes API, keine Tricks für 3rd-Party Programme nötig, um den Scheduler zu beeinflussen)
• Benutzer- Variablen- und Job-Rechtevergabe
• Jobs haben Benutzer- und Gruppenattribute (“Ausführen als”)

CONTRA

• umständlich zu installieren, falls man kein Binärpaket hat (Debian Pakete sind in Arbeit)
• umständliche User Interfaces
• keine (direkte) “Job Chain” Unterstützung
• kleinere Bugs/Unschönheiten (aber nicht im Kernsystem), auch in Arbeit
• läuft Im Kontext der UID 0 (was aber u.A. benötigt wird für verschiedene Benutzerumgebungen)

SOS Scheduler

PRO

• gutes User Interface
• portabel (JAVA)
• direkte Unterstützung von Job Chains

CONTRA

• (für mich als Techniker) nicht so ohne Weiteres intuitiv nachvollziehbar und bedienbar (wann sind wo welche Jobs einzutragen, wieso geht das an tausend verschiedenen Stellen, Hot Folders, statische Konfiguration, etc. etc.)
• Relativ Komplexe Konfiguration, fast wie ein Vollnormalisiertes Datenbankschema, was technisch vielleicht elegant sein mag, aber praktisch ggf. überladen ist
• keine Sperrungen gegen gleichzeitiges Starten von Schedulern mit ein- und derselben Schedulerdefinition
• keine sauberen Fehlermeldungen (mann muss sich durch den JAVA Stacktrace durchbuddeln… und man findet dann irgendwo eine Methode deren Name irgendwas mit “display” zu tun hat – aha, X11 Display kann nicht geöffnet werden)
• keinerlei Dokumentation über Verhalten und Recovery beim Crash der JVM (wahrscheinlich auch nicht möglich nach Crash der JVM – alles was nicht schon in den XML-Dateien ist, ist verloren)
• keine “Multi-JVM” Architektur (ähnlich Multiprozess), d.h. Crash der JVM führt ggf. zum Komplettstillstand des Schedulers, recoverymöglichkeit vage
• man muss sich ein Bein ausreissen um Jobs in verschiedenen Benutzerumgebungen zu starten (eigenes SUID Programm, etc..)

Fazit für mich persönlich

• GNU Batch ist der technisch ausgereiftere und besser gehärtete Scheduler
• die Dokumentation über Recovery nach Crash zeugt von jahrelangem Praxiseinsatz (kein Mensch programmiert Tools zum Auslesen des SHM gleich bei der ersten Version)
• SOS Scheduler ist weitaus besser zu bedienen (aber in Teilen auch etwas umständlicher)
• GNU Batch kann ich selbst supporten und fixen und diese Fixes auch anderen zukommen lassen (ich kann C, aber kein JAVA)
• für GNU Batch kann ich ggf. selbst ein GUI schreiben, da das angebotene API der offiziellen API Library völlig ausreicht (auch netzwerkfähig)

Anfangs hat es genau anders herum ausgesehen, aber ich habe mich (shame on me!) von einem GUI blenden lassen und habe völlig ignoriert, dass die Kernaufgabe eines Schedulers das Scheduling ist. Weiter graben werde ich daher im GNU Batch Scheduler.

Nachsatz

Bevor jetzt Beschwerden aus der einen oder anderen Richtung kommen, oder von irgendwelchen Benutzern die mir sagen wollen das wäre doch alles ganz anders und ich hätte den Kern verfehlt: Dies ist nur ein Report wie ich für mich persönlich in einem kleinen Vergleich einen Kandidaten herausgefunden habe, bei dem es sich eher zu lohnen scheint tiefer zu graben als bei einem anderen Kandidaten. Andere Tester mögen (auch aus anderen Gründen oder duch andere Sichtweisen) zu anderen Ergebnissen kommen.

Hier geht es nicht darum, GNU Projekte zu verherrlichen und/oder SOS Software schlecht zu machen (nur um es mal gesagt zu haben).

I have a small LDAP setup running for centralized Linux authentication since years, using the NSS and PAM modules from PADL Software Pty Ltd.

A few weeks ago I found the nss-pam-ldapd from Arthur de Jong and found the architecture is promising and fixes some problems with the design of the PADL modules.

This project needs contributors, so if you

• have time
• know some C
• like LDAP
• have ideas
• can test

it would be nice to see you there.

I also contributed a line or two.

am Augusttreffen der Linux User Group Mitterteich habe ich einen kleinen Vortrag über das Konzept von X und X Nutzung gehalten.

Ich glaube dass zumindest einige Aspekte des Vortrags auf gutes Interesse gestossen sind, Klagen habe ich zumindest keine gehört. Da ich dazu tendiere lange und umfangreich zu reden…

Das Handout gibt es hier (PDF, ca. 3MB)

In diesem Sinne: Noch einen schönen Abend

Today, somebody (thanks exaltis on Freenode) provided me a link to an OSNews article during a discussion about X. He told me it’s fun to read – I clicked.

In this article (also read the comments), Thom Holwerda talks about why the X Window System is bad and Linux needs a different graphics architecture. This article is nice to read and discusses existing problems in some applications and X server software.

All problems he talks about are real, yes. I can understand that he’s pissed off. And he, as end-user, wants a solution and a stable system.

But his conclusions that these problems come from the design of the X Window System itself are just wrong and show that he doesn’t know what the design of X is. X has enough problems in its design, but none of them are related to the problems in his article. He talks about bad design, but he actually means bad implementation. Even his example with driver crashes or driver updates are completely irrelevant for the X design, the X Window architecture allows ways to implement this. That nobody does this doesn’t mean it’s a design problem.

From what I can see in the text he just would say to me that he’s a user and not a tech and he doesn’t care and he just wants a working system.

Yes, right, he’s a user. That’s why he shouldn’t conclude it’s a design problem, he should just talk about what he knows and not about what he thinks he knows.

super noob question , how do i query my oracle database online, do i need to setup bind9 and allow incoming connections so it can be accessed

I just wanted to share that

Have a good day!

• Backup/exports
• Shutdown DB, remove userspace files
• Cleanup files inside ASM
• DBCA to make new one (no scripts available)

You see, nothing unusual. So far so good, everything fine except the last step. The scripts I had from the first installation didn’t run through, so I just wanted to click something together. But DBCA spit out:

DBCA could not startup the ASM instance configured on this node. To proceed with database creation using ASM you need the aSM instance to be up and running. Do you want to recreate the ASM instance on this node?

Er.. what? ASM instance is up and running and some minutes before the old database ran fine with it! So what? Metalink, Google: Environment variables, Listener configuration etc etc etc. Nothing applied. The only thing I really knew 100% was that the ASM setup was rocksolid.

DBCA failed in the following cases in my experiments (I removed and re-added ASM instance):

• it detected offline ASM and failed trying to start it
• it detected online ASM and failed
• it detected no ASM, successfully created one, and failed to add disks etc..

Long story short: Every combination of DBCA and ASM actions failed.

After several hours we got the solution. I was about to give up and manually rewrote another DB installation script to use it for this DB environment. The last hours we turned around nearly every bit of that installation, we nearly did everything except reinstall the software. We even rebooted the server . My collegue was hopeless, too. But we both were fanatic to find the “why” – it was one of these things where workarounds may work, but don’t satisfy the admins.

I hacked a glogin.sql startup file several weeks ago, that displays a nice prompt with instance and username and some timing statistics when you use SQL*Plus. This is something fine and useful for me (and in general).

But we (infact my collegue) found out:

DBCA seems to communicate with the ASM instance using SQL*Plus. My changed output (infact only the prompt and the time statistics) made the SQL*Plus text parsers of DBCA going crazy. Without one word in the right direction in any log of DBCA. DBCA log always said it found the ASM disks and listed them (in the log). So, it was a simple text parsing issue! The developers of DBCA or the JAVA-classes that manage the communication seem to assume that nobody personaziles his SQL*Plus. Only bad software makes such assumptions

Now I know why ORACLE recommends to use different ORACLE_HOMEs. I didn’t try it, but I can imagine that the SQL*Plus of the ORACLE_HOME from the ASM instance is used when different.

The evening in numbers:

• applies to ORACLE software 10.2.0.4, most likely others, too
• happened on SLES10 SP2
• may be documented somewhere, but I didn’t find it on min. 200 pages I read on the Internet
• gave us min. 500 million new grey hairs
• took us 5 hours

I really begin to love ORACLE At least life isn’t boring…

• Sat Feb 14 00:31:30 CET 2009 -or-
• Fri Feb 13 23:31:30 UTC 2009 -or-
• Epoch 1234567890

please don’t forget to celebrate UNIX!

Additionally, I hope this event helps me to remember the valentine day at least this year

I’ll post an update if Feb 13th has come, to wake you up…

If you send postcards (address in Imprint, also by email), I’ll publish them here!

UPDATE-01:

Found a link. You can even buy T-shirts and stuff. eek, 1234567890 Merchandising…

UPDATE-02:

Do not forget 1234567890!

UPDATE-03:

We survived that day. Good. See you @2000000000!

http://bash-hackers.org/wiki/doku.php/bash4 http://wiki.bash-hackers.org/bash4

Enjoy, comments and edits welcome.