Hozzászólások
-
Bejegyzés
-
Több mint 30 éve létezik „Bank API”, de a doksit csak külön szerződés aláírása után fogsz kapni. Azon ne lepődj meg, hogy a havi díja általában magasabb, mint a havi fizetésed. Nagyüzemi felhasználásra találták ki, nem magánszemélyeknek.
Egy szolgáltatás a sok közül:
https://www.otpbank.hu/OTP_Portal/online/BH02020401000000.jspVan célmegoldás is mint a PayPal, de ez nem alkalmas általános számlakezelésre.
https://www.paypal.com/developerAmit szerenél az jelenleg nem biztonságos, ezért egy banknak sincs ilyen szolgáltatása. Ez esetben jobb a szolgáltatás hiánya, mint több tízezer felelőtlen ügyfél dühöngése.
Több mint 30 éve létezik „Bank API”, de a doksit csak külön szerződés aláírása után fogsz kapni. Azon ne lepődj meg, hogy a havi díja általában magasabb, mint a havi fizetésed. Nagyüzemi felhasználásra találták ki, nem magánszemélyeknek.
Egy szolgáltatás a sok közül:
https://www.otpbank.hu/OTP_Portal/online/BH02020401000000.jspVan célmegoldás is mint a PayPal, de ez nem alkalmas általános számlakezelésre.
https://www.paypal.com/developerAmit szerenél az jelenleg nem biztonságos, ezért egy banknak sincs ilyen szolgáltatása. Ez esetben jobb a szolgáltatás hiánya, mint több tízezer felelőtlen ügyfél dühöngése.
A wine nem emulálja a windows API-t, így nem implemenálja a DirectX alrendszert sem. Ezért nincs dxdiag.exe fájl. A wine OpenGL hívásokra fordítja a DirectX API hívásokat (wrapper).
Viszont valahogyan fel lehet telepíteni a Microsoft féle DirectX 9c-t, akkor lesz végre dxdiag. (Ez a verzió lenne a WineX ?) De így le kell cserélni a meglévő dx*.dll könyvtárakat.
A wine nem emulálja a windows API-t, így nem implemenálja a DirectX alrendszert sem. Ezért nincs dxdiag.exe fájl. A wine OpenGL hívásokra fordítja a DirectX API hívásokat (wrapper).
Viszont valahogyan fel lehet telepíteni a Microsoft féle DirectX 9c-t, akkor lesz végre dxdiag. (Ez a verzió lenne a WineX ?) De így le kell cserélni a meglévő dx*.dll könyvtárakat.
uhlaci wrote:A time.conf beállításait figyelembe is veszi, hiszen ha egy „régi” felhasználónak átírom a time.conf-ban az időpontjait, megváltozik, hogy mikor léphet be, azaz szerintem a squid „használja” a pam.d/squid-be beírt pam_time.so-ra vonatkozó részt.Ez megint ellentmondás, korábban azt írtad hogy rossz a pam_time modul. Szerintem jól működik és más hiányzik.
uhlaci wrote:Tegnap óta már bennem is motoszkál a kérdés, hogyha a pam.d/squid-ből mindent kitörlök, akkor miért is ugrik fel az azonosítást kérő ablak?Ezért, mert azt mondtad a squid proxy-nak, hogy „acl password proxy_auth; http_access allow password”, azaz használjon azonosítást. Ez független attól, hogy a PAM mit csinál és mit nem. Ha mindezt megelőzi egy másik „http_access” szabály, akkor nem dob fel bejelentkező ablakot, hanem végrehajtja amit tartalmaz (allow vagy deny). Nem is válaszoltál, hogy van-e másik http_access sor.
uhlaci wrote:Szóval: 1. Fogalmam sincs, hogy jól van-e kitöltve, szerintem igen, hiszen a „kívánságaim” szerint működött eddig:(Van az úgy, hogy a látszólagos és a valós működés eltér. Szerintem hiányzik a hitelesítés a PAM konfigból (pl. pam_unix), ezért nem is értem mi dobta vissza a régi felhasználók rossz jelszavát. Abban sem vagyok biztos, hogy az új felhasználók rendesen fel vannak véve a rendszer (helyi) felhasználók közé (csoport, home, /sbin/nologin, shadow rendben). Valami alapvető konfigurációs különbség biztosan van a régi és az új felhasználók között.
uhlaci wrote:3. A naplózással egyenlőre még sáros vagyok.Csak a napló alapján lehet kideríteni egyértelműen, hogy engedi be a PAM a régi felhasználókat, és a újakat miért nem. Egészen addig csak torpedó játékot lehet játszani.
uhlaci wrote:A time.conf beállításait figyelembe is veszi, hiszen ha egy „régi” felhasználónak átírom a time.conf-ban az időpontjait, megváltozik, hogy mikor léphet be, azaz szerintem a squid „használja” a pam.d/squid-be beírt pam_time.so-ra vonatkozó részt.Ez megint ellentmondás, korábban azt írtad hogy rossz a pam_time modul. Szerintem jól működik és más hiányzik.
uhlaci wrote:Tegnap óta már bennem is motoszkál a kérdés, hogyha a pam.d/squid-ből mindent kitörlök, akkor miért is ugrik fel az azonosítást kérő ablak?Ezért, mert azt mondtad a squid proxy-nak, hogy „acl password proxy_auth; http_access allow password”, azaz használjon azonosítást. Ez független attól, hogy a PAM mit csinál és mit nem. Ha mindezt megelőzi egy másik „http_access” szabály, akkor nem dob fel bejelentkező ablakot, hanem végrehajtja amit tartalmaz (allow vagy deny). Nem is válaszoltál, hogy van-e másik http_access sor.
uhlaci wrote:Szóval: 1. Fogalmam sincs, hogy jól van-e kitöltve, szerintem igen, hiszen a „kívánságaim” szerint működött eddig:(Van az úgy, hogy a látszólagos és a valós működés eltér. Szerintem hiányzik a hitelesítés a PAM konfigból (pl. pam_unix), ezért nem is értem mi dobta vissza a régi felhasználók rossz jelszavát. Abban sem vagyok biztos, hogy az új felhasználók rendesen fel vannak véve a rendszer (helyi) felhasználók közé (csoport, home, /sbin/nologin, shadow rendben). Valami alapvető konfigurációs különbség biztosan van a régi és az új felhasználók között.
uhlaci wrote:3. A naplózással egyenlőre még sáros vagyok.Csak a napló alapján lehet kideríteni egyértelműen, hogy engedi be a PAM a régi felhasználókat, és a újakat miért nem. Egészen addig csak torpedó játékot lehet játszani.
Már kezdem érteni mi hogy van beállítva a szervere.
uhlaci wrote:A régi felhasználók rendben tudnak internetezni a proxyn keresztül, miután megadják a jelszavukat, ssh-n keresztül, w3m-el tesztelem itthonról.Szerintem a régi felhasználókat nem a PAM lépteti be. Az új felhasználókkal nem megy a PAM, azért nem tudnak belépni. Vagy a régi felhasználóknál nem 1:1 a proxy:rendszer leképezés.
uhlaci wrote:A pam.d önyvtár squid fájljában már csak egy sor van: account required pam_tim.so debugEz jól működik a log-ból ítélve, csak a jelszó ellenőrzés hiányzik. Ha nincs szabály minden mehet, de ha van account controll, akkor auth is kell.
uhlaci wrote:Ha rossz időpontban próbálkozik vagy elüti a nevét vagy a jelszavát elüti, az auth.logban meglelenik egy sor. De! Ha új felhasználóval próbálkozom, wrong password or username hibaüzenettel elutasít a w3m-en keresztül a proxy, viszont auth.logban semmi, syslog, dmesg, …. minden 100-szor átnyálazva.Kevered a samba/squid témát, a samba log bejegyzés hatására nem fog a squid naplózni. Alapból ki van kapcsolva, mert nagy fogalom esetén megeszi a vinyót és lassítja a rendszert. A logrotate meg nem nagyüzemi megoldás.
squid.conf:
debug_options ALL, 9uhlaci wrote:Ha a fenti sort törlöm, akkor új felhasználó simán netezhet. Ha elüti a jelszót, akkor az auth logban megjelenik egy új sor:(Nekem ez ellentmondásnak tűnik. Ha üres a PAM config akkor valahonnan veszi a beállításokat. Nem ismerem jól a Debiant, talán van default szabály valahol? Egyátalán a PAM írja be azt az új sort, vagy a squid?
uhlaci wrote:Már sokat szívtam ezzel a nyomorult időzítéssel, valakinek valami jó ötlete nincs a time.conf kikerülésére?A pam_time jól működik, a többi beállítással van a probléma. Mivel a squid és a samba is képes sokféleképpen hitelesíteni, a mix nem mindig sikerül jól. Viszont mindkettő képes külső forrásból hitelesíteni, így akár saját magad is írhatsz egy beléptető rendszert.
Ha nem akarsz konfig fájl beküldeni az nem gond, csak meg kelle erősítened pár dolgot:
1. a squid és a samba PAM jól van kitöltve
2. sem a squid, sem a samba nem hitelesít máshonnan mint a PAM
3. mindegyik konfigban be van kapcsolva (az alapból kikapcsolt) naplózás
4. 1:1 a leképezés az alkalmazás és a rendszer felhasználói közöttMár kezdem érteni mi hogy van beállítva a szervere.
uhlaci wrote:A régi felhasználók rendben tudnak internetezni a proxyn keresztül, miután megadják a jelszavukat, ssh-n keresztül, w3m-el tesztelem itthonról.Szerintem a régi felhasználókat nem a PAM lépteti be. Az új felhasználókkal nem megy a PAM, azért nem tudnak belépni. Vagy a régi felhasználóknál nem 1:1 a proxy:rendszer leképezés.
uhlaci wrote:A pam.d önyvtár squid fájljában már csak egy sor van: account required pam_tim.so debugEz jól működik a log-ból ítélve, csak a jelszó ellenőrzés hiányzik. Ha nincs szabály minden mehet, de ha van account controll, akkor auth is kell.
uhlaci wrote:Ha rossz időpontban próbálkozik vagy elüti a nevét vagy a jelszavát elüti, az auth.logban meglelenik egy sor. De! Ha új felhasználóval próbálkozom, wrong password or username hibaüzenettel elutasít a w3m-en keresztül a proxy, viszont auth.logban semmi, syslog, dmesg, …. minden 100-szor átnyálazva.Kevered a samba/squid témát, a samba log bejegyzés hatására nem fog a squid naplózni. Alapból ki van kapcsolva, mert nagy fogalom esetén megeszi a vinyót és lassítja a rendszert. A logrotate meg nem nagyüzemi megoldás.
squid.conf:
debug_options ALL, 9uhlaci wrote:Ha a fenti sort törlöm, akkor új felhasználó simán netezhet. Ha elüti a jelszót, akkor az auth logban megjelenik egy új sor:(Nekem ez ellentmondásnak tűnik. Ha üres a PAM config akkor valahonnan veszi a beállításokat. Nem ismerem jól a Debiant, talán van default szabály valahol? Egyátalán a PAM írja be azt az új sort, vagy a squid?
uhlaci wrote:Már sokat szívtam ezzel a nyomorult időzítéssel, valakinek valami jó ötlete nincs a time.conf kikerülésére?A pam_time jól működik, a többi beállítással van a probléma. Mivel a squid és a samba is képes sokféleképpen hitelesíteni, a mix nem mindig sikerül jól. Viszont mindkettő képes külső forrásból hitelesíteni, így akár saját magad is írhatsz egy beléptető rendszert.
Ha nem akarsz konfig fájl beküldeni az nem gond, csak meg kelle erősítened pár dolgot:
1. a squid és a samba PAM jól van kitöltve
2. sem a squid, sem a samba nem hitelesít máshonnan mint a PAM
3. mindegyik konfigban be van kapcsolva (az alapból kikapcsolt) naplózás
4. 1:1 a leképezés az alkalmazás és a rendszer felhasználói közöttEddig nem kérdeztem, a nyomkövetési mód is mindenhol be van kapcsolva?
pam.conf: (a többi modulnak sem árt a debug)
account required pam_time.so debugsmb.conf:
log level= 4 auth:10
legutóbbi hsz