MOLEHAND Solutions

 
Print  
By Halász István on 2016. 07. 29. 16:38

​Ha a Win 10-re frissítés után eltűnne az EFS fájlok színezése, az nem azért van, mert a 10-es Excplorerben már nincs ilyen funkció, csak kikapcsolódott a beállításoknál.

Visszakapcsolás: Beállítások -> Nézet -> Titkosított és tömörített  NTFS fájlok megjelenítése színekkel opció bepipál

By Szontágh Ferenc on 2016. 06. 08. 17:41

A lenti szabály példa annyival tér el egy általános szervertől, hogy itt az Asterisk szolgáltatásokon van a hangsúly. 

A szabályt úgy értelmezzük, hogy alapértelmezetten az OUTPUT szabály engedélyezve, az INPUT szabály "eldob"-ra van állítva a FORWARD-dal egyetemben:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

Természetesen a fenti 3 parancssori parancsot csak is kizárólag azután futassuk le, miután megbizonyosodtunk arról, hogy a már felvett szabályok hibátlanok, ellenkező estben kizárhatjuk magunkat az "INPUT DROP" paranccsal egyből a parancs kiadását követően. Abban az esetben nem lesz elérhető a gép távolról!

A lenti példa copy+paste alkalmas az "iptables-restore" ​paranccsal használható:

#loopback interface-en minden forgalmat engedelyezunk
-A INPUT -i lo -j ACCEPT
#RTP portok, amelyen keresztül folyik a SIP hang
-A INPUT -p udp -m udp --dport 10000:20000 -j ACCEPT
#52580-as TCP port a User Control Panel portja, egyes PBX disztok kulon portra allitjak ba, ujabb distroknal a 80-as porton erheto el, ezer kikommenteztem
#-A INPUT -p tcp -m tcp --dport 52580 -j ACCEPT​
#ISymphony webes portja, amennyiben be van kapcsolva a modul
-A INPUT -p tcp -m tcp --dport ​58080 -j ACCEPT
#IAX2 port, csak abban az esetben, hogyha van IAX kliens beallitva, csak UDP-n erheto el
-A INPUT -p udp -m udp --dport 4569 -j ACCEPT
# sip.ephone.hu, abban az esetben, hogyha van ephone-os trunk, ellenkezo esetben trunkonkent kulon erdemes engedni a szolgaltato IP-jet, amennyiben sip trunkrol van szo
-A INPUT -s 82.150.61.51/32 -p udp -m udp --dport 5060:5061 -j ACCEPT
#ebben a peldaban beengedunk minden forgalmat az 5060-as portra, hogyha vannak 'vandor' kliensek, akik kintrol is csatlakoznak.
#egyes esetekben az 5061-et is engedni kell, az a titkositott SIP port, szinten UDP-n
-A INPUT -p udp -m udp --dport 5060 -j ACCEPT
#hibas, vagy kamu user-agent-eket, hibas kereseket kitiltjuk az 5060-5061-es port tartomanybol
-A INPUT -p udp -m udp --dport 5060:5061 -m string --string "User-Agent: VaxSIPUserAgent" --algo bm --to 65535 -j DROP
-A INPUT -p udp -m udp --dport 5060:5061 -m string --string "User-Agent: friendly-scanner" --algo bm --to 65535 -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p udp -m udp --dport 5060:5061 -m string --string "REGISTER sip:" --algo bm --to 65535 -m recent --set --name VOIP --rsource
-A INPUT -p udp -m udp --dport 5060:5061 -m string --string "REGISTER sip:" --algo bm --to 65535 -m recent --update --seconds 60 --hitcount 12 --rttl --name VOIP --rsource -j DROP
-A INPUT -p udp -m udp --dport 5060:5061 -m string --string "INVITE sip:" --algo bm --to 65535 -m recent --set --name VOIPINV --rsource
-A INPUT -p udp -m udp --dport 5060:5061 -m string --string "INVITE sip:" --algo bm --to 65535 -m recent --update --seconds 60 --hitcount 12 --rttl --name VOIPINV --rsource -j DROP
#ebben a peldaban az SSH a 9222, nem szabad elfelejteni atirni fail2ban-ba is az ssh portot, hogyha alternativ van beallitva
-A INPUT -p tcp -m tcp --dport 9222 -j ACCEPT
#alap 80-as port, a webinterface-hez
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
#HTTPS
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
#a mar meglevo kapcsolatokat tovabb engedjük
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
#a fenti szabalyokban nem letezo bejovo csomagokat eldobaljuk
-A INPUT -j DROP
#minden kimeno csomagot atengedunk kerdes nelkul
-A OUTPUT -j ACCEPT

By Kálmán Dávid on 2016. 04. 24. 18:47

​https://community.spiceworks.com/topic/945472-has-anyone-used-this-software-sqlbackupfree

By System Account on 2016. 03. 26. 22:27

​Előfordul (főleg alaplapcserénél), hogy a rendszer nem bbotol be még csökkentett módban is. Két tool, ahogy offline szerekszthetjük ezeket a példányokat (pl. recovery consolból, vagy valamelyik hiren toolból):

dism.exe ezzel a programmal különböző rendszermódosításokat hajthatunk végre pl. driver telepítés/eltávolítás:

http://www.dowdandassociates.com/blog/content/howto-repair-windows-7-install-after-replacing-motherboard/

/image:C:\ -al szerkesztjük a C-n lévő offline példányt
/Online a futó példányt módosítjuk
//Mount-Image /ImageFile:C:\test\x.wim /index:1 /MountDir:C:\wim -al pedig wim vagy vhd oprendszereket módosíthatunk.

További info: https://msdn.microsoft.com/en-us/library/windows/hardware/dn898558(v=vs.85).aspx

Registry load hive:
Ezzel pedig a registry-t módosíthatjuk. Pl letiltunk egy service-t:

https://support.microsoft.com/en-us/kb/927525

 

By Halász István on 2016. 03. 25. 20:49

​Ha feltesszük a Windows Server Backup feature-t 2012-re, és azt tapasztaljuk, hogy nincs GUI, akkor tegyük fel a (nyilvánvalóan összefüggő)

Remote Server Administration Tools / Feature Administration Tools / Network Load Balancing Tools​

featuret is a boldogsághoz. :)

By Halász István on 2016. 02. 01. 2:29

Egy QNAP NAS kapacitás kiterjesztését a webes felületen kapott hibaüzenet esetén az alábbiak alapján tudjuk manuálisan elvégezni.

 

A hivatalos eljárás szerint cseréljük ki az egyik, majd a másik HDD-t, mindig megvárva, hogy a rendszer szinkronizálja őket.

Ezek után a webes felületen megnyomott Expand capacity gomb hatására a rendszer elkezdett dolgozni, de 50%-nál hibát írt ki:

RAID size expansion failed!

 

Reboot után másodjára ugyanez volt a helyzet.

Ekkor SSH-n beléptem a konzolra, és megpróbálkoztam manuálisan a dologgal. Ennek a lépései:

 

1. Állítsuk le a service-eket:

[~] # /etc/init.d/services.sh stop

 

2. Unmountoljuk a volume-ot:

[~] # umount /dev/md0

 

Ha sikerül az unmount, ugorjunk az ötös pontra!

 

3. Esetemben nem sikerült, valószínűleg ezért nem sikerült a bővítés a webes felületen. Listázzuk ki a nyitott fájlokat:

[~] # lsof /share/MD0_DATA/

 

COMMAND     PID     USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME

squid     12831    admin  txt    REG    9,0  2160952 9110073 /share/MD0_DATA/.qpkg/Squid/opt/sbin/squid

squid     12831    admin    3u   REG    9,0     4253 9112056 /share/MD0_DATA/.qpkg/Squid/opt/var/squid/logs/cache.log

squid     12833 httpdusr  cwd    DIR    9,0     4096 9111955 /share/MD0_DATA/.qpkg/Squid/opt/var/squid

squid     12833 httpdusr  txt    REG    9,0  2160952 9110073 /share/MD0_DATA/.qpkg/Squid/opt/sbin/squid

squid     12833 httpdusr    3u   REG    9,0     4253 9112056 /share/MD0_DATA/.qpkg/Squid/opt/var/squid/logs/cache.log

squid     12833 httpdusr    5u   REG    9,0     4253 9112056 /share/MD0_DATA/.qpkg/Squid/opt/var/squid/logs/cache.log

squid     12833 httpdusr    9w   REG    9,0       52 9109609 /share/MD0_DATA/.qpkg/Squid/opt/var/squid/cache/swap.state

squid     12833 httpdusr   28w   REG    9,0        0 9112051 /share/MD0_DATA/.qpkg/Squid/opt/var/squid/logs/access.log

squid     12833 httpdusr   33w   REG    9,0        0 9112048 /share/MD0_DATA/.qpkg/Squid/opt/var/squid/logs/store.log

ncsa_auth 13209 httpdusr  txt    REG    9,0    15160 9110109 /share/MD0_DATA/.qpkg/Squid/opt/libexec/squid/ncsa_auth

ncsa_auth 13209 httpdusr    2u   REG    9,0     4253 9112056 /share/MD0_DATA/.qpkg/Squid/opt/var/squid/logs/cache.log

ncsa_auth 13210 httpdusr  txt    REG    9,0    15160 9110109 /share/MD0_DATA/.qpkg/Squid/opt/libexec/squid/ncsa_auth

ncsa_auth 13210 httpdusr    2u   REG    9,0     4253 9112056 /share/MD0_DATA/.qpkg/Squid/opt/var/squid/logs/cache.log

ncsa_auth 13211 httpdusr  txt    REG    9,0    15160 9110109 /share/MD0_DATA/.qpkg/Squid/opt/libexec/squid/ncsa_auth

ncsa_auth 13211 httpdusr    2u   REG    9,0     4253 9112056 /share/MD0_DATA/.qpkg/Squid/opt/var/squid/logs/cache.log

ncsa_auth 13212 httpdusr  txt    REG    9,0    15160 9110109 /share/MD0_DATA/.qpkg/Squid/opt/libexec/squid/ncsa_auth

ncsa_auth 13212 httpdusr    2u   REG    9,0     4253 9112056 /share/MD0_DATA/.qpkg/Squid/opt/var/squid/logs/cache.log

ncsa_auth 13213 httpdusr  txt    REG    9,0    15160 9110109 /share/MD0_DATA/.qpkg/Squid/opt/libexec/squid/ncsa_auth

ncsa_auth 13213 httpdusr    2u   REG    9,0     4253 9112056 /share/MD0_DATA/.qpkg/Squid/opt/var/squid/logs/cache.log

squid_uni 13214 httpdusr  txt    REG    9,0     9804 9110108 /share/MD0_DATA/.qpkg/Squid/opt/libexec/squid/squid_unix_group

squid_uni 13214 httpdusr    2u   REG    9,0     4253 9112056 /share/MD0_DATA/.qpkg/Squid/opt/var/squid/logs/cache.log

squid_uni 13215 httpdusr  txt    REG    9,0     9804 9110108 /share/MD0_DATA/.qpkg/Squid/opt/libexec/squid/squid_unix_group

squid_uni 13215 httpdusr    2u   REG    9,0     4253 9112056 /share/MD0_DATA/.qpkg/Squid/opt/var/squid/logs/cache.log

squid_uni 13216 httpdusr  txt    REG    9,0     9804 9110108 /share/MD0_DATA/.qpkg/Squid/opt/libexec/squid/squid_unix_group

squid_uni 13216 httpdusr    2u   REG    9,0     4253 9112056 /share/MD0_DATA/.qpkg/Squid/opt/var/squid/logs/cache.log

squid_uni 13217 httpdusr  txt    REG    9,0     9804 9110108 /share/MD0_DATA/.qpkg/Squid/opt/libexec/squid/squid_unix_group

squid_uni 13217 httpdusr    2u   REG    9,0     4253 9112056 /share/MD0_DATA/.qpkg/Squid/opt/var/squid/logs/cache.log

squid_uni 13218 httpdusr  txt    REG    9,0     9804 9110108 /share/MD0_DATA/.qpkg/Squid/opt/libexec/squid/squid_unix_group

squid_uni 13218 httpdusr    2u   REG    9,0     4253 9112056 /share/MD0_DATA/.qpkg/Squid/opt/var/squid/logs/cache.log

unlinkd   13219 httpdusr  txt    REG    9,0     4356 9110111 /share/MD0_DATA/.qpkg/Squid/opt/libexec/squid/unlinkd

 

4. Lőjük ki a fájlokat nyitva tartó processeket!

[~] # kill 12831

[~] # kill 12833

[~] # kill 13209

[~] # kill 13210

[~] # kill 13211

[~] # kill 13212

[~] # kill 13213

[~] # kill 13214

[~] # kill 13215

[~] # kill 13216

[~] # kill 13217

[~] # kill 13218

[~] # kill 13219

 

5. Indísunk egy fájlrendszer ellenőrzést:

[~] # e2fsck -f /dev/md0

 

6. Terjesszük ki a fájlrendszert:

[~] # resize2fs -p /dev/md0

 

resize2fs 1.41.4 (27-Jan-2009)

The filesystem is already 732174389 blocks long.  Nothing to do!

 

A fenti üzenet volt az eredmény, azaz nem volt már hová kiterjeszkedni.

 

7. Ezt ellenőrihetjuk az alábbi paranccsal:

[~] # mdadm -D /dev/md0

 

/dev/md0:

        Version : 1.0

  Creation Time : Wed May 22 21:12:01 2013

     Raid Level : raid1

     Array Size : 2928697556 (2793.02 GiB 2998.99 GB)

  Used Dev Size : 2928697556 (2793.02 GiB 2998.99 GB)

[további sorok kivágva]

 

3-ról 6 TB-osra kellett bővíteni a RAID tömböt, mint látható, a webes felület még eddig sem jutott el, hogy fizikailag kiterjessze a tömböt.

 

8. Terjesszük ki fizikailag a tömböt a meglévő plusz tárhelyre:

[~] # mdadm --grow /dev/md0 --size=max

 

mdadm: component size of /dev/md0 has been set to 5850567620K

 

9. Terjesszük ki a fájlrendszert (egy darabig eltart):

[~] # resize2fs -p /dev/md0

 

resize2fs 1.41.4 (27-Jan-2009)

Resizing the filesystem on /dev/md0 to 1462641905 (4k) blocks.

The filesystem on /dev/md0 is now 1462641905 blocks long.

 

10. Kapcsoljuk vissza a service-eket az alábbi két paranccsal, ekkor megúszhatjuk a reboot-ot:

[~] # storage_boot_init 2

[~] # /etc/init.d/services.sh start

 

11. Nekem hibát dobott a storage_boot_init script, hogy nem ismer kettes kapcsolót, így én nem úsztam meg. :)

[~] # reboot

By Halász István on 2016. 02. 01. 1:34

SSD klónozáskor elkövettem azt a „hibát”, hogy csatlakoztattam az SSD-t a klónozandó rendszerhez, hogy ellenőrizzem, hogy minden oké-e vele. Ennek az a mellékhatása lett, hogy az SSD kapott egy betűjelet.

Erről viszont érdemes tudni, hogy a Windows megjegyzi az adott betűjelet minden háttértárhoz, és próbálja mindig ugyanezt a betűjelet adni nekik, azaz maximum akkor fog másik betűjelet kapni az eszköz, ha egy másik, korábban csatlakoztatott eszköznek (pendrive pl.) már épp  ki lett adva a betűjel.

 

Ennek az lett az eredménye, hogy klónozás után után nem indult a rendszer, a hibaüzenet alapján a Windows nem találta meg a rendszermappát, azaz a C:\Windows mappát. Ez pontosan azért történt, mert klónozás után, a régi hdd-t kiszerelve már hiába volt szabad a C: betűjel, a rendszer a korábban adott betűjelet adta az SSD-nek.

 

Az indítási javítás nem fog segíteni, mert hiába tudja majd a rendszerindító procedúra, hogy (pl.) az E:\Windows helyen találja a rendszermappát, csincsillió helyen be van drótozva a registry-be, hogy a rendszermappa márpedig a C:\Windows alatt van.

Azaz sokkal egyszerűbb azt a registry bejegyzést módosítani, ami azt mondja meg, hogy az ilyen-és-ilyen ID-jú SSD-nek  a betűjele E: legyen.

 

Ennek menete:

1.       Indítsunk el egy regedt32-t egy rescue lemezről, vagy egy Windows telepítő lemezről. Az utóbbi eset lépései:

a.       bootoljunk be a telepítő lemezről

b.      a grafikus felület megjelenése után bármikor Shift-F10-et nyomva kapunk egy parancssort

c.       ebben adjuk ki a Regedt32 parancsot

2.       Álljunk a HKEY_LOCAL_MACHINE kulcsra (fontos!)

3.       File menü -> Struktúra betöltése… / File -> Load hive…

4.       Tallózzuk ki és csatoljuk fel a System registry fájlt [HKEY_LOCAL_MACHINE \SYSTEM] a következő elérési úton:
%windir%/system32/config/system

5.       adjunk egy nevet, ami alatt a struktúra meg fog jelenni az editorban, pl:
halott_gep_system

6.       a további teendőkhöz kövessük ezt az útmutatót:
How to restore the system/boot drive letter in Windows

 

By Nikolett Tóth on 2015. 10. 04. 14:31

Legkönnyebben úgy lehet megoldani, ha új jelszót generáltatunk a két DC között. Az alábbi cikk szeint.
Win Server 2012 R2-n is működik.
 

By Halász István on 2015. 09. 25. 12:32

Az összes telepített hotfixet a

wmic qfe list

paranccsal tudjuk kilistáztatni. Ezt a listát a /output: kapcsolóval vagy egy sima átirányítással tudjuk szövegfájlba menteni. Ha azonban konkrét számú frissítések esetleges meglétét akarjuk ellenőrizni, akkor felesleges file-ba menteni az outputot, amikor rögtön le is szűrhetjük a findstr parancsba csövezéssel. Ekkor idézőjelek között, szóközzel elválasztva kell megadni a KB számokat:

wmic qfe list | findstr "KB3050265 KB3070102"

Ha egy Windows 7-es géppel kapcsolatban lassúságra panaszkodnak, akkor ugye július óta mindenki azzal kezdi az hibakeresést, hogy ellenőrzi a KB3050265-ös update meglétét, és ha nincs telepítve, akkor felteszi? A fenti módszerrel ez egész gyorsan kivitelezhető. ;)

By Kálmán Dávid on 2015. 09. 21. 20:09

Van egy weboldal, ahol meg lehet nézni hogy melyik felhő szolgáltatást (pl.: Skype, Teamviewer, Gmail) hányan jelentették hibásnak, óránként lebontva: https://downdetector.com/

 

 

Discount offer

 I’ve already tried several providers. Currently all of our projects are placed at MOLEHAND, because they provide real services not only a piece of a computer. Any kind of new problem crops up, I can always count on a fast and expert reaction.