glsldevil binära

Ungefär ett år sedan skrev jag om OpenGL / GLSL debugger glsldevil i artikeln gentoo ebuild för glsldevil-1.1.5 och gav en Gentoo ebuild för det. Unfortunately glsldevil verkar inte finnas längre från webbsidan vid universitetet i Stuttgart ( http://cumbia.informatik.uni-stuttgart.de/glsldevil/ ), som har gjorde ebuild oanvändbar.

Eftersom licensen för glsldevil tillstånd omfördelning, bestämde jag mig för att ladda upp min lokala kopia för att göra glsldevil tillgänglig för allmänheten igen. Tyvärr innehåller endast Linux binärfiler (32bit och 64bit) och varken Windows binärfiler eller källkoden.

Du kan ladda ner Linux binärer från här: glsldevil-1.1.5.tar.gz (15)

För användning med ebuild, bara kopiera filen till / usr / portage / distfiles /.

gäller
Jürgen

1 Star2 Stars3 Stars4 Stars5 Stars (1 röster, genomsnitt: 5.00 av 5)
Loading ... Laddar ...

php-5.4.1_rc1 misslyckas med apache-2.4.1 på gentoo

Idag apache-2.4.1 ebuild har dykt upp i gentoos portageträdet. Framväxande php-5.4.1_rc1 misslyckas med en installerad apache-2.4.1 webbserver på Gentoo med följande felmeddelande:

Konfigurering SAPI moduler
kontroll av AOLserver stöd ... nej
kontroll av Apache 1.x module support via DSO genom APXS ... nej
kontroll av Apache 1.x module support ... nej
kontrollera om du vill aktivera Apache charset kompatibilitet alternativet ... ingen
kontroll av Apache 2,0 filter-module support via DSO genom APXS ... nej
kontroll av Apache 2,0 handler-module support via DSO genom APXS ...

Tyvärr, jag kan inte köras APXS. Möjliga orsaker följer:

1. Perl är inte installerat
2. APXS hittades inte. Försök att passera vägen med-med-apxs2 = / sökväg / till / APXS
3. Apache byggdes inte med-enable-det (är APXS användningssidan visas)

Utgången av / usr / sbin / APXS följande:
. / Configure: line 8325: / usr / sbin / APXS: Ingen sådan fil eller katalog
configure: error: Avbryter

Anledningen till detta är, att den körbara APXS inte blir installerade med apache-2.4.1 ebuild. Enligt gmane.org denna fråga blev fast med apache-2.4.1-r1 ebuild. Men efter uppgradering apache till 2.4.1-r1 framväxande php fortfarande inte med samma felmeddelande. En snabb titt på filsystemet visar att / usr / sbin / APXS blev installerat liksom / usr/sbin/apxs2 symboliska länken blev skapat.

mittelerde sbin # ls-alsh APXS *
24K-rw-r-r-1 root root 23K 1. April 16:14 APXS
0 lrwxrwxrwx 1 root root 14 1. April 16:14 apxs2 -> / usr / sbin / APXS

Detta avslöjar också orsaken till framväxande PHP inte med apache-2.4.1-r1. Den / usr / sbin / APXS perl-script kommer med apache-2.4.1-r1 ebuild saknar körbara flaggan.

Sålunda en enkel

chmod + x / usr / sbin / APXS

löser frågan och framväxande php efteråt fungerar som en charm. Troligen kommer detta att få fast med nästa apache ebuild. För att få apache konfigurationen fungera efter 2,4 uppgraderingen kanske du vill läsa: Uppgradera till 2,4 från 2,2 .

Jürgen favicon php 5.4.1 rc1 fails with apache 2.4.1 on gentoo  php 5.4.1 rc1 fails with apache 2.4.1 on gentoo favicon php 5.4.1 rc1 fails with apache 2.4.1 on gentoo  php 5.4.1 rc1 fails with apache 2.4.1 on gentoo

 php 5.4.1 rc1 fails with apache 2.4.1 on gentoo
1 Star2 Stars3 Stars4 Stars5 Stars (Inga betyg ännu)
Loading ... Laddar ...

iptables spegel mål för Linuxkärnan 3,3

Efter min sista kärnuppgradering jag försökte bygga iptables spegeln målet publiceras här . Iptables spegeln Målet tar paket som skickas till din maskin och returnerar samma paket till maskinen paketet kom ifrån. Således, låt oss säga att någon försöker att skanna din dator eller försöker en attack han skulle söka sin egen maskin eller ens attackera sin egen maskin. När jag försökte med kärnversionen 3,3, gjorde det bygger inte längre med den aktuella Linux-kärnan. Men den här gången bara en mindre modifiering har neccesary. En annan sidhuvudfilen måste ingå och en funktion namn har ändrats. Du kan ladda ner den nyare övergång till kärnan version 3,3 och förmodligen framtida kärnor här:

MIRROR.3.3.0.tar.gz (44) gplv3 127x51 iptables mirror target for linux kernel 3.3

Kärnan modulen har testats med kernel version linux-3.3-vserver-2.3.3.1. Att bygga modulen, starta kärnan du vill använda modulen med. Efteråt packar upp arkivet och kör compile.sh skriptet att bygga modulen. Sedan köra install.sh skriptet för installation av kompileras modulen i / lib / modules katalog för din kärna.

Nu kan du använda spegeln målet i stället för Avvisa och tappa mål i INPUT, framåt och PREROUTING kedjor, så här i din brandvägg skript:

Kr iptables-A INPUT-j AVSPEGLA

Varning: Användning av spegeln målet kan leda till konstiga resultat, i exempel om du vill ansluta till en iptables skyddas maskin som använder spegeln målet, kan du hamna ansluter till den lokala datorn utan att erkänna det. Det kan också använda mycket bandbredd. Det värsta fallet inträffar om du har två datorer med hjälp av modulen. Dessa maskiner kan hamna i ping pong. Så du har blivit varnad, använd med försiktighet och på egen risk. För mer information se: MIRROR mål .

Nedladdningar för äldre kärnversioner finns nedan. Lägg märke till den version numreringen 2.6.25 fungerar för kärnor upp till 2.6.27. 2.6.28 fungerar även för 2.6.29 och 2.6.30 kärnor. Den 2.6.13 versionen av modulen ska arbeta upp till kärnan version 2.6.16.

MIRROR.2.6.13.tar.gz (680)
MIRROR.2.6.24.tar.gz (1045)
MIRROR.2.6.25.tar.gz (977)
MIRROR.2.6.28.tar.gz (991)
MIRROR.2.6.31 (893)
MIRROR.2.6.35.tar.gz (812)
MIRROR.2.6.36.tar.gz (702)
MIRROR.2.6.37.tar.gz (556)
MIRROR.3.0.7.tar.gz (297)
MIRROR.3.1.0.tar.gz (95)
gplv3 127x51 iptables mirror target for linux kernel 3.3

gäller
Jürgen

 iptables mirror target for linux kernel 3.3
1 Star2 Stars3 Stars4 Stars5 Stars (Inga betyg ännu)
Loading ... Laddar ...

udev-182 behov CONFIG_ DEVTMPFS i kärnan

Efter de senaste uppgraderingarna på min gentoo vserver system som kör en 3.3.0 Linux vserver-kernel (vserver-sources-2.3.3.1), har systemet inte startar upp ordentligt längre. Inga kärnmoduler blev laddad och även nätverksenheter har inte varit tillgänglig efter en omstart. Detta är mer eller mindre värsta fall sedan måste man vara fysiskt framför maskinen och kan inte reparera systemet via ssh fjärrinloggning.

Kärnuppgraderingen var inte orsaken till detta, men uppgraderingen till udev-182. Detta är vad loggen säger:

21 mars 17:20:05 mittelerde / etc / init.d / sshd [5563]: FEL: kan inte börja sshd som net.eth0 inte skulle börja
21 mars 17:20:09 mittelerde / etc / init.d / udev-mount [6075]: udev använder en devtmpfs monterade på / dev för att hantera enheter.
21 mars 17:20:09 mittelerde / etc / init.d / udev-mount [6076]: Det betyder att CONFIG_DEVTMPFS = y krävs
21 mars 17:20:09 mittelerde / etc / init.d / udev-mount [6077]: i kärnan konfigurationen.
21 mars 17:20:09 mittelerde / etc / init.d / udev-mount [6067]: FEL: udev-mount gick inte att starta
21 mars 17:20:09 mittelerde / etc / init.d / udev [6066]: FEL: kan inte börja udev så udev-mount inte skulle börja
21 mars 17:21:06 mittelerde / etc/init.d/net.eth0 [6463]: FEL: interface eth0 inte finns

Med information "CONFIG_DEVTMPFS = y erfordras" loggen innehåller nödvändiga tipset att få saker att fungera. Den CONFIG_DEVTMPFS Alternativet skulle vara aktiverat i kärnan. Efteråt kärnan måste kompileras. Alternativet finns i menuconfig under Device Drivers-> generisk drivrutin alternativ och kallas Bibehålla en devtmpfs filsystem att montera på / dev. För att få devfs monteras automatiskt vid uppstart är det klokt att också göra det möjligt för devtmpfs alternativet automount på / dev Efter kärnan monterat rootfs (CONFIG_DEVTMPFS_MOUNT).

Det är säkert att dessa optioner med äldre udev versioner. Om du gör det skyddar ditt system från inte fungerar längre när du får udev uppdateringen senare.

Jürgen

 udev 182 needs CONFIG  DEVTMPFS in kernel
1 Star2 Stars3 Stars4 Stars5 Stars (Inga betyg ännu)
Loading ... Laddar ...

zen-sources-3,2 med tuxonice

Från och med 2.6.36 kärnan har tuxonice tagits bort från zen-källor. Den senaste officiella tuxonice lapp, som finns närvarande, är för Linuxkärnan 3,0. Under tiden nyare patchar för kärnversionen 3.2.1 och 3.2.10, har dykt upp på crow202.org . Så jag patcha zen-stabil-3.2 källor med den 3.2.1 tuxonice plåstret därifrån.

Suspend to RAM fungerar med denna kärna, åtminstone på min Dell Precison M65 och min Desktop, samt skjuta till disk gör. Dessutom kan jag bekräfta att 3.2.1 patch fungerar även på x86_64-arkitekturen.

Att få saker att fungera, ladda ner zen-stabila-3.2-kärnan träd från Zen-kernel.org och extrahera den. Efteråt hämta 3.2.1 tuxonice patchen från crow202.org och tillämpa den. Efter applicering av plåstret kan du fortsätta med standard kärnan byggprocessen. Som med zen-källor-3.1, är ingen ytterligare patch behövs för zcache funktionen är fix redan i zen-stabil-3.2. Den zcache Funktionen fungerar RAM effektiviteten och samtidigt ge en betydande prestanda boostar på många arbetsbelastning. Den zcache Funktionen finns under mellanstationer förare i kärnan trädet och beror på cleancache funktionen, som finns under processor typer och funktioner. För att aktivera zcache funktionen måste du passera zcache sökord för att din kärna, i exempel i grub.conf.

Exempel: kernel / zImage panic = 60 root = / dev/hda3 zcache

För Gentooanvändare finns ett lättare sätt: Ladda ned mitt modifierade overlay från zen-sources-3.2.tar.gz (52) och extrahera dem i / usr / local / portage. Överlägget innehåller alla nödvändiga patchar. Var noga med att inkludera följande rad i din / etc / make.conf:

PORTDIR_OVERLAY = "/ usr / local / portage"

Om du vill använda tuxonice inkludera tuxonice i din USE-flaggor. Då dyker zen-källkoden och bygga kärnan som du vill.

Tuxonice stöds inte officiellt i dagens zen-källor. Så Om du använder filerna ovan, rapporterar inte alla buggar till zen-sources.org. Du är på egen hand.

För min Precision M65 Jag använde följande kärnan config: config_zen_3.2_dell_m65.zip (49)

För mer information om zen-källorna patchset se www.zen-sources.org .

vänliga hälsningar

Jürgen

 zen sources 3.2 with tuxonice
1 Star2 Stars3 Stars4 Stars5 Stars (Inga betyg ännu)
Loading ... Laddar ...

Liten felrättningsutgåva i extcalllog CallerID modifikation N900

I artikeln ser upp telefonnummer med N900 som jag beskrev en lösning för att utföra omvänd uppslagningar telefonnummer inifrån N900 s förlängda samtalslogg. Plåstret och därmed också binärpaketet det innehöll en liten bugg. När det fanns internationella samtal, till att börja med "00", i loggen, inte den omvända lookup på grund av CallerID ansökan inte tolkning av "00" på rätt sätt. Den fasta extcalllog Ansökan översätter nu dessa avslutande nollor till en "+" som blir tolkas korrekt av CallerID ansökan.

Nedladdningar i den ursprungliga artikeln har uppdaterats nu.

Jürgen

1 Star2 Stars3 Stars4 Stars5 Stars (Inga betyg ännu)
Loading ... Laddar ...

qemu-kvm med cache = ingen förlorar på ext4 filsystem med journal_data option

Kvm har blivit en av de stora virtualiseringstekniker de senaste åren. För Redhat Linux har det även blivit standard virtualiseringslösning. Kvm har IO prestanda är knappast konkurrera med andra virtualiseringslösningar när du använder standardalternativen. Speciellt när man använder qcow2 bilder kan IO prestanda KVM / qemu förbättras avsevärt genom att inaktivera cache av underliggande värden filsystemet. Detta kan göras genom att starta kvm med cachen = ingen möjlighet, i exemplet med alternativen

-Drive file = my_image.qcow2, index = 0, media = disk, cache = ingen

istället för att bara förse bild med-hda my_image.qcow2. Sedan bildfilen öppnas med hjälp av O_DIRECT flaggan, förbi sidan cache. Om den underliggande filsystemet inte stödjer O_DIRECT flaggan misslyckas detta med felmeddelandet:

kunde inte öppna skivavbilden my_image.qcow2: Ogiltigt argument

Detta är fallet för en ext4 filsystem med full aktiverad journalföring. Man kan enkelt testa om O_DIRECT flaggan stöds av det underliggande filsystemet med en enkel kommandot dd på värden:

dd if = some_file of = / dev / null iflag = Direkt

Om O_DIRECT flaggan inte stöds det leder till följande fel:

DD: öppning `some_file": Ogiltigt argument

Således, om säkerhetsproblem inte är tillämpliga, inte vill man inte använda fullt journalföring, för att öka prestanda. Journaling alternativ kan ställas in antingen i / etc / fstab eller i filsystemet sig. För fstab fallet med röda märkt del av följande exempel inträde måste avlägsnas.

/ Dev/sda7 / ext4 defaults, noatime och nodiratime och asynkrona, data = journal 0 1

Om journalföring alternativet ligger i filsystemet, kan detta visas och redigeras med tune2fs kommandot. I exempel tune2fs-l / dev/sda7 visar information om filsystemet på / dev/sda7. Om full journalföring är aktiverat innehåller mata ut journal_data mount alternativ:

Default monteringsalternativ: journal_data

Alternativet kan tas bort med tune2fs-o ^ journal_data / dev/sda7. Efteråt utsignalen tune2fs-l inte innehåller journal_data ingsalternativet längre:

Default monteringsalternativ: (none)

I båda fallen filsystemet måste återmonteras för att aktivera ändringarna. Efteråt qemum-kvm arbetar med cachen = ingen möjlighet, som beskrivits ovan, och med ökad IO prestanda.

Jürgen

Referenser:
[1] itscblog.tamu.edu
[2] blog.nkadesign.com

 qemu kvm with cache=none fails on ext4 filesystem with journal data option
1 Star2 Stars3 Stars4 Stars5 Stars (Inga betyg ännu)
Loading ... Laddar ...
2012/02/15

mygnu information

Blog Roll

Site Info

Trans lator

English flagItalian flagKorean flagChinese (Simplified) flagChinese (Traditional) flagPortuguese flagGerman flagFrench flag
Spanish flagJapanese flagArabic flagRussian flagGreek flagDutch flagBulgarian flagCzech flag
Croatian flagDanish flagFinnish flagHindi flagPolish flagRomanian flagSwedish flagNorwegian flag
Catalan flagFilipino flagHebrew flagIndonesian flagLatvian flagLithuanian flagSerbian flagSlovak flag
Slovenian flagUkrainian flagVietnamese flag