OSX 10.4 – Dashboard kikapcsolása

Posted by kovix in Macintosh, OSX on dec 31st, 2008 | 0 comments

Még az elején szögezzük le: A Dashboard jó dolog. A Dashboard hasznos dolog. A Dashboard szép dolog.

Arra, amire kitalálták, tökéletesen megfelelő. Csak leütjük az F12 billentyűt (vagy a képernyő megfelelő sarkába vonszoljuk az egeret), és máris hasznos minialkalmazások hada lepi el a képernyőnket.

Abban az esetben, ha Macunk nincs bővében a az életető memóriának, mégis célszerű lehet megszabadulni a dashboard-tól. A minialkalmazások akkor is foglalják a memóriát, ha éppen nem látjuk őket, és a dashboard is a memóriában csücsül.

A kikapcsolásukhoz indítsunk el egy terminal-t (Applications/utilities), és adjuk ki az alábbi parancsot (Normál user-ként):

defaults write com.apple.dashboard mcx-disabled -boolean YES

A parancs hatására a dashboard a következő induláskor már nem fog futni. Ahhoz, hogy azonnal megszabaduljunk tőle, a dock újraindítására van szükség, ezt pedig megtehetjük az alábbi paranccsal (kicsit dúrva, de hat…):

killall Dock

Ha újra szeretnénk a Dashboard-ot használni, a

defaults write com.apple.dashboard mcx-disabled -boolean NO
killall Dock

parancs párossal újra élvezhetjük a minialkalmazásokkal tarkított desktopunkat…

OSX Root jelszó (Root felhasználó engedélyezése)

Posted by kovix in Macintosh, OSX on dec 28th, 2008 | 0 comments

Sok Mac felhasználó tette már fel nekem a kérdést, hogy osx alatt a root felhasználót hogyan lehet elérni.

A root felhasználó az UNIX jellegű rendszerekben az “Isten”, a korlátozások nélküli, bármire képes felhasználó. A bármire képes, itt szó szerint bármire képes… Kárt is tud tenni, és itt nincs meg a windowsos jó tündér (Biztos benne, hogy meg akarja nyomni a biztos benne gombot?). Ha törölni akarunk, töröl. Elhiszi hogy mi jobban tudjuk – akkor is ha nem.

Szóval, hogy kerítsük elő ezt a felhasználót? Az esetek többségében semmi szükség rá (de azért megmutatom, hogyan kell életre bírni)!

Rendelkezésünkre áll a sudo parancs, amely a paraméterként kapott parancsot rendszergazdai jogosultságokkal hajtja végre, és cserébe csak a saját jelszavunk érdekli.

Például, a 

sudo nano /etc/hostconfig

a nano /etc/hostconfig parancsot fogja rendszergazda módban végrehajtani (máshogy nem lenne jogosultságunk elmenteni a változtatásokat), és az aktuálisan bejelentkezett felhasználó jelszavát kell beírni neki. Természetesen a megemelt jogosultsági szint csak az adott munkafolyamatra (parancsra) érvényes, minden már korábban elindított, illetve sudo parancs használata nélkül kiadott parancsra az átlagos felhasználói jogosultságok az érvényesek.

Lehetőségünk van arra, hogy egy konzolt rendszergazdai módba helyezzünk, ehhez a 

sudo -s

és a saját jelszavunk megadása szükséges. Sikeres alkalmazása esetén visszakapjuk a parancsértelmező promtját, és kilépésig (vagy exit parancsig) minden parancsunk rendszergazda módban fog végrehajtódni.

 

A root felhasznákó engedélyezése

a legegyszerűbb mód a

sudo passwd root

parancs használata, amellyel beállíthatunk egy új jelszót a root felhasználónak, amellyel aztán be tudunk jelentkezni.

Konzolról a

su

parancs segítségével válthatunk rendszergazda módba.

MySQL Master-Slave replikáció

Posted by kovix in Uncategorized on dec 26th, 2008 | 8 comments

MySQL adatbáziskezelő szerver esetén lehetőségünk van replikikációra, azaz az adatokst módosító (beszúrás, update, törlés, stb.) szinte azonnali továbbítására kerülnek egy távoli szerverre is, így az adatokon végzett módosítások ott is végrehajtásra kerülnek.

A megoldás ugyan elég távol áll egy terhelés-eolsztásos clustertől (A master node-ot írni és olvasni is tudjuk, de a slave-et csak olvasni), de ettől haszna még bőven akad:

Egyszerű failover megoldásnak tekinthető: Ha a master szerver elhasal, az adatok gyakorlatilag real time ott vannak a slave-en, csak meg kell neki mondani, hogy Ő mostantól nem slave.

Ha túl sok, vagy túl nagy adatbázisaink vannak, akkor a mysqldump-os megoldás problémás lehet a nagy erőforrásigény, a hosszú mentési idő, és a még hosszabb visszaállítási idő miatt. Ilyen esetben célszerű az adatfájlok közvetlen mentése. Tekintettel arra, hogy a MySQL szerver működése során memóriába pufferel adatokat, ha egy futó MySQL szerver alól kimentjük az adatfájlokat, korántsem biztos hogy minden adat a fájlban lesz, illetve hogy az adatfájl egyáltalán használható lesz egy visszaállítás után. Kézenfekvő a megoldás: slave szerverre replikáljuk az adatokat, majd mentés előtt a slave szervert leállítjuk. Szolgáltatásunk működését ez nem befolyásolja, hisz a kliensek továbbra is a master szerverrel kommunikálnak, a master pedig a binlogban gyűjti, azokat az utasításokat, amelyeket a slave-nek végre kell hajtania, hogy újra az aktuális állapotot tükrözze. A leállított slave adatfájljait ezután gond nélkül menthetjük, majd a mentés végzetével a slave adatbázis szerver ujraindításával minden megy tovább.

A master – slave replikáció megvalósítása:

(tovább…)

Symantec (Norton) Antivírus és tűzfal eltávolítása a jelszó ismerete nélkül

Posted by kovix in Windows on dec 13th, 2008 | 0 comments

A Symantec (Norton) Antivirus illetve Internet Security termékek eltávolítása során – ha a telepítéskor azt beállítottuk – szükségünk lehet egy adminisztrátori jelszó megadására, amely megakadályozza a véletlen , vagy szándékos károkozás céljából történő eltávolítást.

Ha az eltávolítási jelszót elfelejtettük, az alábbi módszerrel megkerülhetjük a jelszókérési ablakot, így eltávolíthatjuk a szoftvereket:

Indítsuk el a regisztrációs adatbázis szerkesztőt. (Start menü -> futtatás -> gépeljük be a regedit parancsot és üssünk Entert. (lehetséges, hogy szükségünk lesz egy rendszergazdai jelszóra a futtatáshoz.)

A megjelenő ablakban navigáljunk el az alábbi elemhez a bal oldali fastruktúrában:

HKEY_LOCAL_MACHINE -> Software -> Intel -> LanDesk -> VirusProtect6 -> CurrentVersion -> AdministratorOnly -> Security

A jobb oldali ablakrészen keressünk egy “UseVPUninstallPassword” nevű, “REG_DWORD” típusú bejegyzést, majd kattintsunk kétszer a nevén.

A megjelenő ablakban állítsuk 0-ra az értékét, majd OK gomb megnyomásával és a regedit bezárásával lépjünk ki az alkalmazásból.

A Norton termékek ezek után a szokásos módon eltávolíthatóak.

php exec() – Unable to fork warning windows alatt

Posted by kovix in PHP, Windows on dec 8th, 2008 | 0 comments

Windows (IIS / Apache) alatt futtatott php 5.x alatt, ha exec függvényt próbálunk hívni, könnyen az alábbi hiba (figyelmeztetés) fogadhat minket:

"Warning: system() [function.system]: Unable to fork".

esetleg

"Warning: shell_exec() [function.shell-exec]: Unable to execute"

A probléma okozója az, hogy hiába van a php kódot futtató felhasználónak (általában IUSR_gépnév) jogosultsága a kérdéses állományt végrehajtani, a php exec() függvénye nem közvetlenül azt próbálja futtatni, hanem a cmd.exe-t, aminek paraméterben adja át a futtatni kívánt parancsot.

Így, a működéshez a cmd.exe-re is megfelelő jogosultságot kell adnunk. A cmd.exe elérési útvonala: %windir%\system32\cmd.exe (Általában c:\windows\system32\cmd.exe vagy c:\winnt\system32\cmd.exe)

A fájlon jobb klikk, tulajdonságok (properties)

 

 

 

Amennyiben az INTERNET GUEST ACCOUNT (IUSR_gépneve) nincs a listában, kattintsunk a hozzáadás(add gombra), és a mezőbe írjuk be az IUSR szöveget, majd nyomjuk meg a Névellenőrzés gombot. (Apache esetén válasszuk azt a felhasználót, amely nevében az apache folyamatok futnak.)

 

Fontos!!! Határozottan ellenjavallott több jogosultságot adni az IUSR felhasználónak, mint amennyi a képen látható