[ENC]BladeXP's Blog

Was die Welt nicht alles braucht!

Einträge in der Kategorie „Debian”

LVM kann jetzt endlich mergen...

geschrieben von encbladexp am 28.07.2010 11:33:00.

Auf der Ubucon 2008 habe ich ja einen Vortrag über LVM gehalten.

Das ganze hat mir viel Spaß gemacht, und ich denke auch bei den Teilnehmern kam das Thema gut an. Einziger Kritikpunkt waren die LVM-Snapshots, den diese konnte man damals zwar erstellen, aber nicht einfach mal eben zurücksichern.

Dies ist jetzt möglich da Kernel und LVM-Tools die nötigen Patches erhalten und akzeptiert haben. Man benötigt dafür aber Kernel 2.6.33 sowie LVM-Tools in Version 2.02.58 welche es leider nicht mehr in Lucid geschafft haben. Somit muss man auch auf der aktuellen LTS Version, auf dieses sinnvolle Feature verzichten.

Debian Testing hat die benötigte Version der LVM-Tools schon in den Paketquellen, allerdings ist zu hoffen das 2.6.33 es vielleicht doch noch schafft.

pyNeighborhood 0.5.1rc2

geschrieben von encbladexp am 20.07.2010 11:38:00.

Heute haben wir pyNeighborhood in der Version 0.5.1rc2 veröffentlicht. Hier der Eintrag vom Launchpad.

Für Ubuntu gibt es natürlich wieder ein PPA (Link), für Arch Linux ein AUR (Link) und für Debian kommen Pakete sobald die Final Version 0.5.1 veröffentlicht wurde.

Es werden noch freiwillige gesucht die im Launchpad die Übersetzungen für andere Sprachen wie Deutsch und Englisch fertig machen (Link) könnten.

schroot für Debian/Ubuntu mit Arch

geschrieben von encbladexp am 06.07.2010 19:48:00.

Da ich ja neulich von Ubuntu auf Arch gewechselt bin, habe ich dort natürlich keine Tools um Debian Pakete für testing oder diverse PPAs zu bauen.

Dies ist natürlich ärgerlich da ich das ein oder andere Paket natürlich weiterhin für Debian und Ubuntu anbieten will, insbesondere pyNeighborhood ist ja eher für Einsteiger und damit Ubuntu Anwender gedacht.

Damit ich weiterhin diese Pakete bauen kann habe ich mich für schroot entschieden. Damit kann man einfach und effektiv verschiedene chroot Umgebungen verwalten, so das ich mit einem einzigen Befehl in einem Debian System bin.

Für die Installation der benötigen Programme habe ich yaourt verwenden:

yaourt -S debootstrap schroot

Der nächste Schritt bestand daraus ein neues Logical Volume einzurichten und darauf dann ein Debian Basissystem zu packen:

sudo lvcreate -L 5G -n sid main
sudo mkdir /mnt/sid
sudo mount /dev/mapper/main-sid /mnt/sid
sudo debootstrap --arch=amd64 sid /mnt/sid http://ftp.de.debian.org/debian
sudo umount /mnt/sid

Nun müssen nur noch 2 Sachen gemacht werden damit man schroot verwenden kann. Das wichtigste wäre die Anpassung der Datei /etc/schroot/schroot.conf, hier muss dies am Ende der Datei (alternativ auch sonstwo) einkopiert und angepasst werden:

[sid]
type=block-device
device=/dev/mapper/main-sid
root-groups=wheel
Damit kann jeder Benutzer der in der Gruppe wheel ist auch schroot voll verwenden. Natürlich sollte man bei größeren Sicherheitsanforderungen die Manpage der schroot.conf aufmerksam durchlesen! Zusätzlich sollte man noch in der Datei /etc/schroot/default/nssdatabases die Zeile mit networks kommentieren, da sonst ein Start der chroot Umgebung nicht funktioniert, dies liegt daran das Arch Standardmäßig keine /etc/networks hat welche vom Startscript kopiert werden könnte.

Nun kann man mit

schroot -c sid -p
eine Benutzershell in chroot öffnen. Dabei wird sogar das /home-Dateisystem vom Hostsystem übernommen.

Goodbye Ubuntu

geschrieben von encbladexp am 26.06.2010 10:16:00.

Seit ca. 2006 habe ich statt Debian lieber Ubuntu auf den Desktops verwendet. Haupgrund war für mich damals, das viele Pakete einfach viel zu alt sind (in Stable versteht sich), oft waren selbst die Versionen von Testing nicht aktuell genug, um meine Wünsche und Anforderungen zu erfüllen.

Anfangs hat mir Ubuntu (bin ja erst seit Dapper dabei, vorher nur ab und an mal einen Blick drauf geworfen) sehr gut gefallen. Es war aktuell genug das auch der (damals neue) nVidia Treiber mit dem X.org richtig laufen wollte, und ich so meinen neuen 22er TFT richtig nutzen konnte. Unter Debian wollte dieser einfach nicht akzeptieren das meine GeForce mehr als 1280x960 kann.

Das letzte große Release von Ubuntu das ich auf vielen Systemen verwende war bisher Hardy Heron (8.04), auch dies lief, nach kleinen Problemen am Anfang, sehr stabil und zuverlässig. Leider sind 2 Jahre auf dem Desktop für ein Ubuntu LTS fast etwas viel. So musste im Laufe der Zeit ein PPA nach dem anderen die Pakete vom System aktualisieren, was natürlich ein dist-upgrade nach 2 Jahren unmöglich machte. Compiz funktionierte nach einem Wechsel der Grafikkarte (GeForce 9500GT auf GeForce 9600GT) auch nichtmehr zuverlässig, Schuld war wohl ein Bug im nVidia Treiber der nur mit alten X.org Versionen auftaucht. Da ich mir mein System nicht totpatchen wollte gab es halt ab da kein Compiz mehr (irgendwie vermisse ich das mittlerweile überhaupt nicht mehr).

So kam Lucid, dies wurde nicht via dist-upgrade auf mein System gebracht sondern mit einem debootstrap in ein neues LV. Leider durfte ich damit (nach weniger als einer Woche) schon wieder mit PPAs beginnen, den z.B. brauche ich eine neuere v4l-dvb Version damit meine DVB-S2 Karte richtig lief. Dann war gajim noch Broken (kein Weltwunder bei dieser Version) und einige andere Sachen liefen auch nicht so wie ich es erwartet habe. Zum Schluss hat GNOME ab und an einfach vergessen Compiz oder Metacity zu starten, was sicherlich an dem Userprofil liegen mag das ich schon seit Debian Woody immer wieder von einer Installation auf die nächste kopiere.

Nun war mir klar das eine Distribution mit Rolling Releases das einzige wäre das meinen Wunsch nach neuen Programmversionen und schnelleren Bugfixes stillen kann.

Hier gibt es, meiner Meinung nach, nur 4 Möglichkeiten:

  • LFS
  • Gentoo
  • Arch
  • Debian Sid
Sowohl bei LFS als auf bei Gentoo steckt mir einfach zu viel Arbeit dahinter, daher viel meine Wahl (nach einem doch recht kurzen Test) auf Arch. Debian Sid läuft außer Konkurenz, wird bei mir aber in einer VM als Testsystem bleiben müssen.

Natürlich werde ich noch weiterhin auf Ubuntuusers.de und anderen Plattformen Hilfe für Ubuntu Leisten, dennoch werde ich es in Zukunft nichtmehr auf neuen Systemen verwenden. Auf Servern wird in Zukunft wieder Debian Stable zum Einsatz kommen, auf den Clients in Zukunft Arch. Und nur bei Leuten die weniger IT KnowHow haben wird nach wie vor Ubuntu verwendung finden.

Downsizing, Upsizing oder doch was richtiges?

geschrieben von encbladexp am 21.12.2009 20:52:00.

Seit ich meinen SheevaPlug habe, hat mich wieder der alte Spieltrieb gepackt: Welche Linux-Distribution bekommt man auf welcher Hardware ans laufen.

Downsizing

So nennt sich das wenn man versucht eine große Distribution (Ubuntu, Fedora, Debian, $INSERTYOURLINUXHERE, ...) auf ein eigentlich viel zu kleines und leistungsschwaches Gerät zu installieren. Meine Meinung nach ist sowas nicht unbedingt praktisch, und auch nicht gerade das was man sich täglich antun möchte.

Wer schon mal auf einem Pentium III mit 500 MHz und 128MB RAM mit Ubuntu "gesurft" hat, der weis was ich meine!

Upsizing

Auf der anderen Seite gibt es natürlich noch so viele Mini Linux Distributionen (Toms Root Boot Disk, HAL91, ...) welche doch Ideal für so ein kleines Gerät sein müssten. Doch auch hier ist man falsch, die meisten Mini Linux Distributionen gibt es nur für die i386 Architektur, eine Version für ARM oder noch exotischere Prozessoren wird man kaum finden (oder zumindest keinen Support dafür bekommen).

Der Aufwand eines dieser Minimalsysteme an seine (in der Regel) höheren Anforderungen anzupassen ist nicht gerade gering da oft z.B. der Kernel und viele Basistools ausgetauscht (oder erstmal hinzugefügt) werden müssen.

Viele Stunden rumbasteln nur damit man dem Nachbarn zeigen kann was für ein Toller Hecht man doch ist, naja... ich habe da andere Hobbies ;-)

Doch was richtiges?

Und jetzt kommen wir zu dem (IMHO) richtigen Weg: Man nimmt etwas, das genau für solche Geräte ausgelegt ist. Das allgegenwärtige ist natürlich Linux From Scratch, welches wenn man genug Erfahrung hat wirklich überall laufen sollte. Aber sind wir doch ehrlich: Wir nutzen Computer weil wir verdammt faul sind, nur die wenigsten von uns werfen einen Compiler an ohne zu wissen das es (mit großer Wahrscheinlichkeit) funktionieren wird.

Ich habe mich daher nach einiger Zeit für OpenWRT als Distribution für meinen SheevaPlug entschieden. OpenWRT erfüllt alle meine Anforderungen:

  • Klein, mein aktuelles System (inkl. OpenVPN,iptables,sshd,rsync) ist weniger als 20 Megabyte groß
  • Schnell, der Plug benötigt damit ~20 Sekunden zum booten
  • Funktional, einfach das .tgz + uImage auf eine SD Card entpacken und Spaß haben
  • Erweiterbar, für alles wichtige gibt es Pakete (zum selber bauen)
  • Einfach, make menuconfig und auswählen was man will bekommt (fast) jeder hin

Fazit

Es bringt nichts (außer das die Zeit vorbei geht) wenn man krampfhaft versucht sein Linux das man immer und überall hat auf jedes noch so kleine (oder große) Gerät anzupassen. Natürlich war OpenWRT nur ein Beispiel, ggf. hat sogar schon T2 ein Target für Kirkwood (die Plattform vom SheevaPlug heist so).

Sony DCR-HC51E und Ubuntu

geschrieben von encbladexp am 25.08.2009 19:29:00.

Durch einen Zufall konnte ich heute endlich mal FireWire ausprobieren. Dies liegt daran das ein Arbeitskollege von mir eine Sony DCR-HC51E auf seiner Hochzeit dabei hatte. Leider wusste niemand so genau wie man da Videos runter bekommt :-(

Glücklicherweise verfügt die Kamera über einen Firewire Anschluss so das man mit Kino auch unter Linux ohne große Probleme die Videos von der Kamera bekommt.

Vorbereitung

Firewire

Vorbereiten muss man nicht viel, es genügt wenn die Kernelmodule raw1394 und dv1394 geladen sind:

sudo modprobe raw1394
sudo modprobe dv1394

Software

Als Software ist Kino sehr gut, bei der Fehlersuche ("Steckt die Kamera richtig?") ist gscanbus von Vorteil da man die Bustopologie damit sehen kann:

sudo aptitude install kino gscanbus

Action!

Das einzige was man jetzt noch beachten muss ist, das Kino ja Lese und Schreibrechte auf /dev/raw1394 benötigt. Immer wieder gibt es Anleitungen wie "Nimm einfach den Benutzer in die Gruppe disk mit auf."... Bitte, macht sowas nicht! Den nicht nur /dev/raw1394 hat als Gruppe disk, sondern vor allem auch Datenträger (Festplatten), wodurch es ermöglich wird das man ohne weitere Hürden direkt die Festplatte manipulieren kann, da man ja Schreibrechte direkt auf den Datenträger hat (vorbei am Dateisystem).

Es ist, zumindest wenn man Kino nicht oft braucht viel sinnvoller Kino Temporär als root (mit sudo) laufen zu lassen. Zwar hat Kino dadurch mehr Rechte, und könnte diese durch eine Sicherheitslücke in Kino missbrauchen, aber man öffnet nicht einem User (und somit vielen anderen Sicherheitslücken) die ganzen Datenträger.

Die Sicherheitstechnisch sinnvollste Lösung wäre eine Anpassung der udev Regeln, dies aber auch nur auf den ersten Blick. Den über das IEEE1394 Subsystem ist eh Zugriff auf das restliche System möglich.

Meiner Meinung nach sollte man daher Kino wirklich "einfach" als root (mit sudo) laufen lassen, was sicherlich einigen Administratoren nicht gefallen wird:

sudo kino

Die Videodateien, auch die Exportierten Videos, gehören so aber leider dem Benutzer root. Um das zu ändern kann man dies hier ausführen:

sudo chown benutzer:benutzer /pfad/zu/den/videos/*.dv

Nach diesem Befehl gehören die Dateien dem Benutzer benutzer, und man kann diese wie gewohnt bearbeiten.

Fazit

Video mit Kino von der Firewire tauglichen Kamera zu laden ist relativ einfach. Stolpersteine gibt es eigentlich nur beim Sicherheitsaspekt, was aber wenn man es nicht täglich brauch verschmerzlich ist.

Ich gehe in diesem Artikel nicht weiter auf Kino ein, da es hierfür schon mehr als genug Dokumentation (auch deutsche) im Netz gibt.

Getestet habe ich alles was in diesem Artikel steht unter Ubuntu Hardy Heron (64-Bit, 8.04 LTS), es sollte aber auch auf andere Distributionen übertragbar sein.

Postfix und SpamPD

geschrieben von encbladexp am 28.04.2009 16:35:00.

Ich überlege ja schon ein paar Tage wie ich Postfix mit SpamAssassin verkuppeln kann.

Die meisten Lösungen die ich kenne verwenden dafür ein mehr oder weniger fragwürdiges Script, was mir ehrlich gesagt überhaupt nicht gefällt. Nach ein wenig Recherche im Internet bin ich auf SpamPD gestoßen.

SpamPD läuft als mehr oder weniger Transparenter Mailproxy (SMTP/LMTP) was natürlich Ideal für einen Post-Queue Filter bei Postfix ist. Hier beschreibe ich wie man sowas Debian/Ubuntu Konform in sein Postfix Setup einbinden kann. Bitte beachte das ich nicht darauf eingehen wie ein Mailserver funktioniert und was der tut usw...

Installation

Viel braucht man ja nicht, ein einfaches

sudo apt-get install spampd spamc
genügt vollkommen. Wer will kann natürlich noch zusätzliche Filter für SpamAssassin installieren.

Konfiguration

SpamPD

In der Datei /etc/default/spampd muss nicht viel gemacht werden. Was ich aber machen würde ist das Ändern der letzten beiden Zeilen, so das der ADDOPTS Block mit der separaten Config (/etc/spampd.conf) der ohne Kommentarzeichen davor ist.

Jetzt sollte man dem SpamPD noch neu starten, dies macht man am besten via

sudo /etc/init.d/spampd restart

Postfix

Bei Postfix wird es ein wenig komplexer, den Postfix soll ja alle Mails durch SpamPD jagen. Ich gehe davon aus das man die Defaults aus der /etc/default/spampd nicht weiter verändert hat.

Wenn man seine /etc/postfix/main.cf nicht total versaut hat genügt eine Änderung in der Datei /etc/postfix/master.cf. Zum einen muss natürlich der vorhandene smtpd alle Mails über den SpamPD jagen, dafür muss man diesen Eintrag

smtp      inet  n       -       -       -       -       smtpd
so ändern:
smtp      inet  n       -       -       -       -       smtpd
  -o content_filter=smtp:[127.0.0.1]:10025

Wer Postfix kennt kann dies natürlich auch direkt über die /etc/postfix/main.cf erledigen.

Jetzt sind die Mails zwar im SpamPD, aber dieser will die Mails ja auch wieder an den Postfix bringen (der kümmert sich ja um die Auslieferung an das Ziel). Dafür braucht man folgende Regel in der /etc/postfix/master.cf:

localhost:10026 inet n - n - - smtpd
  -o content_filter=
  -o myhostname=nospam.stefan-betz.net
  -o smtpd_recipient_restrictions=permit_mynetworks,reject
  -o mynetworks=127.0.0.0/8
  -o smtpd_client_restrictions=
  -o smtpd_sender_restrictions=
  -o smtpd_helo_restrictions=
  -o smtpd_client_restrictions=
  -o local_recipient_maps=
Dann noch ein kleiner Neustart von Postfix mit
sudo /etc/init.d/postfix restart
und alles wird gut.

Die Konfiguration von SpamAssassin kann man dann über die /etc/spampd.conf machen welche bei mir so aussieht:

use_bayes 1
bayes_path /var/cache/spampd/bayes
bayes_auto_learn 0
report_safe 0
Natürlich gibt es hier noch jede Menge Raum für Optimierungen ;-)

Firefox Datenbanken komprimieren

geschrieben von encbladexp am 06.01.2009 19:23:00.

Seit einiger Zeit nimmt Firefox ja für mehr und mehr Sachen sog. SQLite Datebanken. Diese sind zwar recht praktisch, werden aber mit der Zeit doch recht groß, und der Firefox natürlich dadurch relativ lahm.

Jemand vom Ubuntuusers Webteam hat mir daher folgenden Tip gegeben:

for f in ~/.mozilla/firefox/*/*.sqlite; do sqlite3 $f 'VACUUM;'; done

Der Befehl sorgt dafür das SQLite die Datenbanken von Sachen befreit die schon längt gelöscht wurden, wie viele andere Dateibasirende Datenbanken gibt auch SQLite seinen schon belegten Speicher nicht einfach so frei. Erst durch VACUUM wird das erledigt, welches Firefox dummerweise nicht selbst macht.

Zuvor sollte Firefox unbedingt beendet werden!

Das hat mir bei meinem Firefox ca. 30 MByte mehr freien Platz gebracht, und natürlich hakt Firefox nichtmehr so sehr wenn man mal in der History rumwühlt.

Evolution: Fehler bei Ordner wird gesäubert

geschrieben von encbladexp am 13.12.2008 16:34:00.

Heute habe ich folgendes Bemerkt als ich Userdaten von einer Ubuntu Gutsy Installation unter Intrepid wiederherstellt habe. Und zwar bekommt man in Evolution wenn man STRG+E (Dieser Shortcut steht für Ordner Säubern) drückt die Fehlermeldung:

  Fehler bei Ordner wird gesäubert.
  Zusammenfassung und Ordner stimmen nicht überein, sogar nach einer Synchronisierung

Im Internet wird oft geraten doch einfach alles aus dem Posteingang in einen neuen Ordner zu sichern und dann den Posteingang zu löschen. Das ist natürlich sehr umständlich, gerade wenn man doch ein paar mehr Ordner hat. Wenn man unter ~/.evolution/mail/local/ schaut findet man dort etliche Dateien. Und zwar für jeden Mailordner eine Datei die so heist wie der Ordner selbst. Dann gibt es für jede Dieser Dateien noch einen Ordner mit dem Namen Ordnername.sbd und dann noch diverse Dateien wie z.B. Ordnername.ev-summary.

Man sollte natürlich vor dem Bearbeiten der Ordnerstruktur den Evolution Data Server mit evolution --force-shutdown beenden! Desweiteren sollte man vor jeder Änderung an der Ordnerstruktur von Evolution ein Backup machen!!!

Man sollte für jeden Unterordner ab ~/.evolution/mail/local/ das hier machen:

rm *.ibex* *.cmeta *.ev-summary*

Dadurch werden die Ordnermetadaten gelöscht, Evolution kümmert sich beim nächsten Start darum das alles wieder passt. Nun wird auch STRG+E wieder funktionieren.

Hochzeit: Squid 3 und Active Directory

geschrieben von encbladexp am 24.11.2008 17:16:00.

Nein, ich heirate nicht. Aber ich habe Squid 3 erfolgreich mit einem Active Directory verkuppelt.

Vorbereitungen

Unter Windows muss folgendes erledigt sein:

  • Proxy Server muss im Microsoft DNS Dienst bekannt sein
  • Proxy Server muss als "Trusted Host" im AD angelegt sein

Der Proxy Server sollte entweder eine "richtige" statische IP, oder auch eine Reservierung via DHCP haben. Auch muss die Uhrzeit mit NTP Synchron gehalten werden, den Kerberos ist sehr pingelig was das angeht!

Auf der Linux Seite benötigt man natürlich den root-Account, oder ähnliche Rechte (sudo usw...). Alle nachfolgenden Befehl müssen als root eingegeben werden!

Proxy Server

Auf dem Proxy Server selbst braucht man folgende Pakete:

  • krb5-user
  • squid3
  • winbind

Kerberos Setup

Die Kerberos Konfigurationsdatei (/etc/krb5.conf) sollte so aussehen:

[libdefaults]
 default_realm = DOMAIN
[realms]
 DOMAIN = {
  kdc = 192.168.1.1
  admin_server = 192.168.1.1
 }
[domain_realm]
.domain = DOMAIN
[appdefaults]
pam = {
 ticket_lifetime = 1d
 renew_lifetime = 1d
 forwardable = true
 proxiable = false
 retain_after_close = false
 minimum_uid = 1
}

In meinem Fall war DOMAIN der Domänenname und 192.168.1.1 dessen IP-Adresse. Es ist natürlich wichtig das man dafür eine Funktionierende Namensauflösung hat, Optimal ist es wenn man dafür den DNS Server vom AD nimmt. Da sollte ja ohnehin alles drin sein was man braucht.

Natürlich ist für das Kerberos Setup ein Test nicht schlecht:

kinit user@DOMAIN

Man wird nun nach dem Passwort für den AD-User user gefragt. Wenn alles geklappt hat bekommt man von klist folgende Ausgabe:

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: user@DOMAIN

Valid starting    Expires           Service principal
11/26/08 20:57:19 11/27/08 06:57:20 krbtgt/DOMAIN@DOMAIN
        renew until 11/27/08 20:57:19

Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached

So sieht man das man erfolgreich ein TGT (eine Art "Chef-Ticket") bekommen hat, mit diesem könnte man dann Ticket für einzelne Dienste anfordern, was uns aber jetzt nicht weiter interessiert.

Samba / Winbindd Setup

Nachdem jetzt Kerberos läuft, können wir an den nächsten Schritt gehen: Samba (genauer Winbind) will jetzt Domänenmitglied werden, und das geht mit so einer /etc/samba/smb.conf:

[global]
workgroup = DOMAIN
realm = DOMAIN
password server = HOSTNAME.DOMAIN
security = ADS
winbind refresh tickets = yes
idmap uid = 10000-20000
idmap gid = 10000-20000
winbind enum users = yes
winbind enum groups = yes
winbind cache time = 10
winbind use default domain = yes

password server muss der DNS Name vom AD Server sein. Der Rest dürfte selbsterklärend sein. Nun kann man der Domäne beitreten:

net ads join -U user@DOMAIN

Dannach kann man den winbindd starten, was wie gewohnt über

/etc/init.d/winbbind start

geht. Ob dies funktioniert hat kann man mit wbinfo -t prüfen:

checking the trust secret via RPC calls succeeded

Dann kann man auch noch die Gruppen im AD anzeigen lassen, dies geht mit wbinfo -g:

gruppe1
gruppe2
gruppe3
usw...

Damit Squid (genauer ntlm_auth) auch was mit Winbind Anfangen kann muss das Verzeichnis /var/run/samba/winbindd_privileged der Gruppe windbind_priv gehören, und von dieser Lesbar sein.

Squid Setup

Jetzt kommt der letzte Schritt, und zwar die Anpassung der /etc/squid3/squid.conf, hier gehört folgendes noch mit rein:

auth_param ntlm program /usr/bin/ntlm_auth --require-membership-of=DOMAIN\\GRUPPE --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 10
auth_param basic program /usr/bin/ntlm_auth --require-membership-of=DOMAIN\\GRUPPE --helper-protocol=squid-2.5-basic
auth_param basic children 5
auth_param basic realm Domain Proxy Server
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off
authenticate_cache_garbage_interval 10 seconds
authenticate_ttl 0 seconds
acl AuthorizedUsers proxy_auth REQUIRED
http_access allow all AuthorizedUsers

Von dem Parameter cache_effective_user bzw. cache_effective_group sollte man die Finger lassen (die Zeile sollte also ein Kommentarzeichen am Anfang haben), da sonst ntlm_auth nicht mit den nötigen Rechten läuft.

Es ist wichtig das der User proxy auch in der Gruppe winbindd_priv ist:

sudo adduser proxy winbindd_priv

Mit diesen Einträgen erreicht man das SSO bevorzugt wird, jedoch auch noch der alte Benutzername/Passwort Dialog möglich ist. Dies ist vor allem dann sinnvoll wenn man nicht nur NTLM fähige Clients hat. Ich habe bei der Gelegenheit auch gleich eingestellt das nur Mitglieder der AD Gruppe GRUPPE das Recht haben ins Internet zu gehen, was gerade in großen Firmen gewünscht wird.

Jetzt kann man mit /etc/init.d/squid3 start den Squid Proxy starten, und kann einen Test unter Windows machen (z.b. mit dem Internet Explorer). Das der Proxy Server auch schön auf den Clients eingetragen wird, davon gehe ich jetzt einfach mal aus.