Synology und Mac OS X Server Open-Directory (LDAP)

Im aktuellen DSM von Synology (DSM 3.2 Beta) kann man auch LDAP-Nutzer und Gruppen einbinden. Die Konfiguration ist dabei recht einfach: In der Systemsteuerung den Eintrag »LDAP« auswählen und den Server-Namen eintragen (beim ersten Test am besten keine Verschlüsselung wählen). Der Basis-DN entspricht dem im Server-Admin eingetragenen LDAP-Suchbeginn und anmelden kann man sich z.B. mit einem eigenen Nutzer (diradmin o.ä.). Der Bind erfolgt mit vollständigem DN, also der Kombination aus Basis-DN und Nutzer (die in cn=users liegen). Wenn also der Basis-DN dc=ldap,dc=domain,dc=tld lautet, so erfolgt der Bind via User diradmin z.B. mit uid=diradmin,cn=users,dc=ldap,dc=domain,dc=tld

Eine Besonderheit fällt auf: Wenn für den Nutzer im Open-Directory über den Arbeitsgruppenmanager verschiedene Kurznamen (Reiter »Allgemein«) für einen Nutzer vergeben wurden, werden diese im Attribut uid gespeichert. Dies führt dazu, dass der LDAP-Nutzer auf der Synology unter dem letzten Kurznamen in der Liste auftaucht. Ist der normale Nutzer-Account z.B. user1 und dessen letzte Kurzname Vorname.Nachname so taucht dieser User als Vorname.Nachname@ldap.domain.tld auf.

Google bringt »Events« als neues Rich-Snippets-Format

Bereits zu Beginn des letzten Jahres hat Google so genannte »Rich Snippets« eingeführt. Diese Snippets sind ein Feature, das es Webseiten-Betreibern ermöglicht, strukturierte Daten von ihren Webseiten in Google Suchergebnissen anzuzeigen. Laut dem Blog-Eintrag in der Google Webmaster-Zentrale gab es begeisterte Reaktionen auf Rich Snippets. Sie sollen den Nutzern bei der Suche von Websites helfen, weil sie es erlauben gezielter zu klicken und noch schneller das Gewünschte zu finden.

Wir haben die Rich Snippets ursprünglich in zwei Formaten eingeführt: Bewertungen (reviews) und Personen (people). Danach haben wir erweiterte Möglichkeiten eingeführt, um Video-Informationen auszuzeichnen und damit die Video-Suche zu verbessern. Heute freuen wir uns, mit einer weiteren Neuerung ins neue Jahr zu starten: Events (Veranstaltungen).

Das neue Format zeigt Links zu bestimmten Veranstaltungen auf der Seite, zusammen mit Datums- und Ortsangaben. Es bietet somit eine schnelle und komfortable Art, um festzustellen, ob eine Seite bestimmte Veranstaltungen enthält, an denen man möglicherweise interessiert ist.

Der ganze Blog-Eintrag: http://googlewebmastercentral-de.blogspot.com/

Using mod_security 2.5 and Apache 2 on Mac OS X

Unfortunately recent MacPorts comes with mod_security 1.8.6 and the maintainer is not actively supporting updates (for details see this ticket). Since I wanted to test some settings on a local Apache installation on my Mac with the latest release (2.5.11) I used the information given in the ticket to patch and update my mod_security port.

This guide is straight forward and shows just the required changes, a working MacPorts installation with Apache 2 is mandatory. You simply have to edit the Portfile that contains the details for mod_security.

Step-by-step explanation

  1. Update your MacPorts installation by sudo port selfupdate and sudo port upgrade outdated (read this guide for more details on MacPorts selfupdate)
  2. Open the portfile for mod_security and replace the content of the file with the provided code. The portfile in my installation resides in/opt/local/var/macports/sources/rsync.macports.org/ release/ports/www/mod_security/Portfile


    Download the Portfile as text file

  3. Now you may install mod_security via MacPorts using this terminal command:sudo port install mod_security
  4. Open the Apache configuration file (/opt/local/apache2/conf/httpd.conf) in a text editor and add mod_security to the list.Open a new Terminal (the Termin.app resides in /Applications/Utilities on your harddrive) window and then type the following command to open and edit the file (the sudo command is required to get write-access to this file since it is normally not writable for you user account).sudo nano /opt/local/apache2/conf/httpd.confNow enter your password (the same you use to log in to your Mac). Use the cursor keys to scroll down to the section for the Dynamic Shared Object (DSO) Support and copy the following line below the last LoadModule… statement (see screenshot).LoadModule security2_module modules/mod_security2.so

    To save and leave the Nano editor press CTRL+X and confirm with Y (for Yes) to save.

  5. Reload the Apache server. The security module should now be loaded by Apache (start or restart Apache to commit changes).sudo /opt/local/etc/LaunchDaemons/org.macports.apache2/apache2.wrapper restart

February 13th, UNIX Time Will Reach 1234567890

February 13th, UNIX Time Will Reach 1234567890: „mikesd81 writes ‚Over at Linux Magazine Online, Jon maddog Hall writes that on Friday the 13th, 2009 at 11:31:30pm UTC UNIX time will reach 1,234,567,890. This will be Friday, February 13th at 1831 and 30 seconds EST. Matias Palomec has a perl script you an use to see what time that will be for you: perl -e ‚print scalar localtime(1234567890),’\n‘;‘ Now, while this is not the UNIX epoch, Alan Cox does assure us that Linux is now working on 64-bit time, and the UNIX epoch ‚roll-over‘ would happen about the time that the sun burnt out.'“

(Via Slashdot.)

Vertrauenserweckende Dialog

Da will man einmal einen Klingelton (natürlich mühsam selbst erstellt) auf sein Telefon laden – und dann das:

itunes_iphone_dialog.png

Der Zusammenhang zwischen manuellem(!) Synchronisieren und der Notwenigkeit zum Löschen aller Titel, Filme und Fernsehsendungen erschließt sich mir nicht.

Is It Time to Ditch IE6?

Is It Time to Ditch IE6?: „On August 27, 2001, almost exactly 7 years ago, Microsoft unleashed Internet Explore 6 upon the world. Despite version 7 having been out now for almost two years, and version 8 already in public beta, usage of the 2001 release remains strong. W3Counter reports that it is still the most popular browser in the world at 34.6% of all visits, while TheCounter.com has it second to IE7, but only barely and still commanding a whopping 36% market share.

Because so many people still use the older version of Internet Explorer, many web sites have made the choice to continue supporting it (including SitePoint — where about 12% of our visitors still come to us using IE6). But is it perhaps time to ditch IE6 support and start forcing people to upgrade?

Web application developer 37signals made the decision to drop IE6 support in July (actual support for Microsoft’s last generation browser ceased on August 15). ‘IE 6 can’t provide the same web experience that modern browsers can,’ wrote 37signals of the decision. ‘Continued support of IE 6 means that we can’t optimize our interfaces or provide an enhanced customer experience in our apps. Supporting IE 6 means slower progress, less progress, and, in some places, no progress.’

According to 37signals, supporting IE6 was holding them back. And 37signals isn’t alone in their dislike of IE6. In 2006, a few months before Microsoft released their last major browser, PC World magazine ranked Internet Explorer 6 as the 8th worst tech product of all time, citing its terrible track record when it comes to security.

Security is such a big issue for IE6, that one blogger recently reported that 95% of all bots accessing his site use Internet Explorer 6 as their user-agent. ‘Most blog spam comes from bots that either fake or, as a trojan, use Internet Explorer 6 of infected systems,’ he wrote, ultimately deciding to block IE6 completely to alleviate the blog spam problem.

Of course, security isn’t the only reason web developers are sour on IE6. Internet Explorer 6 is also dismal when it comes to standards compliance. So why do people continue to use it? As Nick La wrote a year ago, the reason people still use IE6 is that developers go out of their way to make web sites work in it. So most people don’t realize that IE6 isn’t a good browser.

‘We all know that IE6 is outdated and has horrible CSS rendering engine. However, most average Internet users haven’t realized that yet. Why? Because we put our hard work on it and patch the bugs by various IE hacks,’ La wrote, urging people to drop support for IE6.

A third of the Internet is a lot of people to just leave behind, though. So support for IE6 continues at most web sites, especially large ones. What we need to move us forward, however, is a bold move, not too much unlike the one Apple made in 2001 when it decided to forgo backwards compatibility when it released OS X. In order to save the Internet from IE6, perhaps we need to stop supporting it.

What do you think? Should web developers stop supporting Internet Explorer 6? Vote in our poll and then leave your thoughts in the comments below.

Note: There is a poll embedded within this post, please visit the site to participate in this post’s poll.

(Via SitePoint Blogs.)

The Only Thing We Have To Fear Is Premature Standardization

The Only Thing We Have To Fear Is Premature Standardization: „The web is made of open standards. This was a significant factor in the web’s displacement of proprietary application platforms. Openness is hugely attractive, so much so that the web dominates over competitors with better technologies. The difficult tradeoff that comes with a standards-based approach is that it is difficult to innovate. As a result, the basic technologies of the browser have been stalled for a decade. What innovation we’ve enjoyed, such as the Ajax revolution, has come by mining all of the latent, accidental potential of the existing standards. That potential has been used up.

If we are to go forward, we must repair the standards. This is something that must be done with great care. A revision to a standard is an act of violence, just like any surgical procedure. It should only be undertaken when the likely benefit far exceeds the cost and the pain and the risk. The web is particularly troublesome because it did not anticipate the management of software updates, which is why IE5, an ancient browser, still has more users than Safari and Opera combined. Changes to the standard can put developers in a very difficult position because the benefits to users of some browsers become the seeds of failure for the users of others. Developers must manage this gulf, and it is not easy. Developers are not well served by new standards that make their jobs even harder.

I think it is instructive to look at two approaches to managing innovation within a standards based system, one that I view as a success, and the other not so much. JavaScript was a promising but half-baked language that was irresponsibly rushed to market and then irresponsibly cast into a standard. That standard is called ECMAScript to avoid a trademark dispute. That standard was last revised in 1999.

It is clear that the language needs to be updated, but TC39 (the committee that is responsible for drafting a new standard) could not reach consensus on how to do it, so it split into two groups, each producing its own proposal. This was a good thing in that competition is a healthy thing, and I believe that competition inspired improvements to both proposals. This was also a bad thing because no standards organization can adopt two proposal for the same standard. Without consensus, both proposals must fail.

On one side there was the proposal called ES4. It was unfortunate that it adopted that name because it strongly suggested that it was destined to be the Fourth Edition of ECMAScript, a fate that was not certain. The project was very open to new ideas and features, adopting a porkbarrel attitude that was almost Congressional in its expansiveness. Lots of good ideas were included without an adequate analysis of the language as a whole system. As a result, many overlapping features were adopted which would have significantly increased to complexity of the language.

ES4 was so large and so innovative that there were doubts about whether it could be successfully specified and implemented. More worrisome, there was no experience with the language itself. Would the interaction of features cause unintended problems as we saw in ES1 and ES3? The schedule for ES4 required that the standard be put in place and adopted by the browser makers before that question could be answered. This is a problem because once a bug is inserted into a standard, it can be extremely difficult to remove it. All of the features, considered individually, were attractive. But taken as a whole, the language was a mess.

On the other side was a proposal called ES3.1. Its name indicated a less ambitious proposal, being a smaller increment over the current Third Edition. This project was intended to repair as many of the problems with the language as possible while minimizing the pain of disruption. New syntax was considered only when it was already implemented and proven in at least three of the four major browsers. Feature selection tended to favor necessary improvements over desirable improvements.

ES3.1 was more minimal in approach. The set of feature interactions was much smaller and much easier to reason about. ES3.1 is likely to complete its specification and will be the candidate for the Fourth Edition.

ES4 had a large head start (by as much as seven years by some estimates), but was unable to meet its deadlines. Ultimately, the project fell apart when some of the key members left.

Some of the features that were in ES4 were reasonable, so a new project, called Harmony, is starting which will look at adapting the best of ES4 on top of ES3.1. The success of this project will depend on the ability of TC39 to do a better job of managing the tradeoffs between innovation and stability, and adopting a discipline for managing complexity. Simplicity should be highly valued in a standard. Simplicity cannot be added. Instead, complexity must be removed.

It turns out that standard bodies are not good places to innovate. That’s what laboratories and startups are for. Standards must be drafted by consensus Standards must be free of controversy. If a feature is too murky to produce a consensus, then it should not be a candidate for standardization. It is for a good reason that ‘design by committee’ is a pejorative. Standards bodies should not be in the business of design. They should stick to careful specification, which is important and difficult work.

I see similar stories in HTML5. The early work of WHATWG in documenting the undocumented behavior of HTML was brilliant. It went off the rails when people started to just make new stuff up. There is way too much controversy in HTML5. I would like to see a complete reset with a stronger set of design rules. Things can be much worse than the way things currently are. Having smart people with good intentions is necessary but not sufficient for making good standards.

(Via Yahoo! User Interface Blog.)