Sok ISP limitálja manapság a BitTorrent forgalmat. Ez egy részt érthető, másrészt pedig idegesítő – ha felhasználói oldalról nézzük. Konkrétan jelenleg a UPC-nél vagyok előfizető, és ők elég keményen korlátozzák a fájlmegosztó alkalmazások forgalmát. Erre nyújt megoldást a titkosított kapcsolat, és az egyik fórumon a következő tippet kaptam – mely működik is. Rtorrent r00x.

Some ISPs limit the BitTorrent stream with traffic shaping.

To workaround such devil limitation on ISPs, ask rtorrent to try encrypted connections. I have this in my ~/.rtorren.rc:

encryption=allow_incoming,try_outgoing,enable_retry

Even if you ISP does not implement traffic shaping, please crypt-enable your BT client so your connection with those who are shaped may be faster.

rTorrent simply rocks. Started to use it today and it is everything I need.

Popularity: 30% [?]

Az s2ram funkciót mindig is király feature-nek tartottam, és most végre sikerült megcsinálni. Ubuntu 8.10 alatt először az volt a problémám, hogy resume esetén nem volt kép. Az itt található útmutatót felhasználva, a következőket tettem:

Először is az /etc/X11/xorg.conf -ban:

Section “Device”
…
Option “NvAGP” “1″
EndSection

Aztán az /etc/default/acpi-support -ban:

SAVE_VBE_STATE=false

A végeredmény, hogy működik. Most már teljes értékű a médiacenter, XBMC-vel teszteltem, és 1mp alatt online minden.

Popularity: 17% [?]

A mai napon, az egyik szerverünkön nem volt hajlandó elindulni az Apache2. A címben látható hibaüzenetre a google szerencsére sok jó megoldást ad, lássuk ami nekem is működött:

ipcs -s | grep nobody | perl -e 'while (<STDIN>) { @a=split(/\s+/); print `ipcrm sem $a[1]`}'

Figyelem, a nobody user helyett olyan user-t kell megadni, mellyel az apache2 fut. Természetesen csak akkor használjátok ezt a parancsot, ha van elég hely az apache2 logok számára:)

Amúgy a hibát nem értem pontosan, valahogy a web szerver úgy hal el, hogy a memóriában szemetet hagy maga után.

Popularity: 24% [?]

Újabb problémával találkoztam M-M témakörben. A hibaüzenet most ez: (show slave status\G; -ból)

Last_Error: Could not parse relay log event entry. The possible reasons are: the master’s binary log is corrupted (you can check this by running ‘mysqlbinlog’ on the binary log), the slave’s relay log is corrupted (you can check this by running ‘mysqlbinlog’ on the relay log), a network problem, or a bug in the master’s or slave’s MySQL code. If you want to check the master’s binary log or slave’s relay log, you will be able to know their names by issuing ‘SHOW SLAVE STATUS’ on this slave.

A fenti problémára (amennyiben a Master oldal rendben van) a következő a megoldás a slave-n:

localhost:(none)> slave stop;
localhost:(none)> slave stop; localhost:(none)> CHANGE master TO master_log_file=Relay_Master_Log_File,master_log_pos=Exec_Master_Log_Pos
localhost:(none)> slave start;

A Relay_Master_Log_File és Exec_Master_Log_Pos paramétereket a show slave status\G; paranccsal kaphatjuk meg. A problémáról további információ itt olvasható.

Egy kis illusztráció:

Popularity: 26% [?]

Adott egy Master-Master replikáció, és az egyik Masteren leállt a slave processz:

mysql> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
       
Slave_IO_Running: Yes

Slave_SQL_Running: No

A szinkronizáció tehát a két szerver között leállt. A hiba gyors "elhárítása" :

mysql> stop slave;

mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER=n (én 1-et állítottam be)

mysql> start slave;

A slave ezzel elindult, és a szinkronizáció elkezdődött…. most már csak ki kell nyomozni, hogy mitől állt le, illetve azokat a táblákat, melyek valamiért nem tudnak szinkronizálódni manuálisan kell javítani.

Popularity: 23% [?]