Maris-S

Ja Tu domā tieši kāda saistība IMEI ar bloķēšanu no sakaru operatoru puses, tad vienmēr ir tāda bijusi. Nezinu vai viņi bloķē tieši IMEI, taču identificē pēc tā. Vai tagad ir kas mainījies, to gan nezinu. Agrāk nosaucot viņiem sērijas numuru varēja uzzināt vai telefons nav kādā veidā pie viņiem nobloķēts. Aktuāli pērkot lietotos telefonus. Neesmu pārliecināts vai tāpat ir arī tagad.

Nezinu kā tagad ir ar IMEI kodu, bet vismaz tieši par bloķēšanu agrāk varēja uzzināt no mobilo sakaru operatoriem. Piemērs tīri no dzīves, kādreiz viens paziņa bija iegādājies pa lēto mobilo, šķiet ka viņš pat strādāja Tele2 tīklā, kad uzzvanījām uz LMT apjautājamies par viņa IMEI, atbildēja ka šis telefons pie viņiem skaitās kā nozaudēts vai nozagts. Par to, vai tāda informācija ir pieejama tagad un vai ir pieejama online, gan nezinu. Iespējams kāds zinošāks cilvēks par šo varēs ko vairāk pateikt.

Centos nelietoju, bet vienīgais kas nāk prātā ir tas, ka php būs jāpārkompilē pašam, izmantojot jaunos MySql libus, mēģini pameklēt kaut ko tajā virzienā. Paskaties kādus configure parametrus izmanto Centos pakotnes kompilēšanai, to var redzēt ar php_info() un pārkompilē. Protams to jādara uz datora kur jau ir uzlikts jaunākais MySql ar visiem libiem un headeriem un visiem pārējiem dpendenčiem, ko vajag php kompilēšanai.

Vienkāršā failu šārošana Tev neder? Ja es protams pareizi sapratu ko gribi panākt.

Aaxc, es saskatīju, kaut gan nemēģinu pārliecināt ka pareizi sapratu. Kā jau teicu, to lai domā moderatori, ja domā ka jāatstāj kā ir, tad lai paliek.

Codez, tas vairāk aicinājums moderatoriem, bet paldies par labojumiem latviešu valodā. :)

Pa lielam moderatori jau sen varēja atdalīt jautājumu un manu atbildi, kas, izskatās, ir vienīgā (neiešu apgalvot ka ļoti laba) tēmai atbilstoša un pārējo censoņu radošās domas atsevišķā tēmā. Tas tā, manas domas, ja moderatoriem protams rūp foruma satura kvalitāte.

Ja par tēmu, tad pirmais kas nāk prātā, vari salīdzināt storage engines, t.i. InnoDB, MyIssam, utt. Apskati ar ko atšķiras, kādas iespējas, domāju tur diezgan daudz ko var pētīt.

Forumā nestrādā edit, nevaru izlabot iepriekšējo kodu, pareizāk laikam būtu tā: if($summa > $z50 and $v4 == 0 ) { echo "<div class='message_success'>text1</div>"; } elseif($summa > $z25 and $summa <= $z50 and $v3 == 0 ) { echo "<div class='message_success'>text2</div>"; } else { echo "<div class='message_error'>text3</div>"; }

Ja es vispār pareizi sapratu ko Tu gribi panākt, tad apmēram tā: if($summa > $z50 and $v4 == 0 ) { echo "<div class='message_success'>text1</div>"; } elseif($summa > $z25 and $summa < $z50 and $v3 == 0 ) { echo "<div class='message_success'>text2</div>"; } else { echo "<div class='message_error'>text3</div>"; } kodu nepārbaudīju.

Sveiki! Kārtējo reizi gribēju lūgt padomu. Jautājums būtu par servera monitorēšanu un drošību. Pagaidām monitorēšanai esmu uzlicis collectd, izvēlējos to, jo tas tiek visur aprakstīts kā mazāk prasīgs pret resursiem, kas ļauj veidot salīdzinoši mazus monitorēšanas intervālus, līdz ar to sasniegt diezgan augstu precizitāti. Vēl ir doma kādreiz izmēģināt Nagios, Zabbix un Cacti. Tagad parādās jautājums pieredzējušiem administratoriem, kādas monitorēšanas iespējas ieteiktu izmantot? Vēl jautājums par monitorēšanu ir, vai ir jēga likt atsevišķus monitorēšanas rīkus, piemēram, tīkla plūsmas monitorēšanai - ntop? Tad vēl jautājums par drošību. Par antivīrusiem, ugunsmūriem tā kā viss būtu skaidrs, bet tagad domāju kā būtu ar tādiem rīkiem kā HIDS un NIDS, visticamāk tie būtu Samhain un Snort. Nekad agrāk tos nelietoju, cik aktuāla ir šo rīku izmantošana? Īpaši ņemot vērā ka bezmaksas Snort rules datubāze ir pieejama tikai 30 dienas veca. Kādi būtu ieteikumi par šāda veida rīkiem un varbūt ir jēga apskatīt kādus citus drošības rīkus? Būtībā varētu jau to visu pēc kārtas uzinstalēt un lai viņš tur viss strādā, bet, ja būs viss uzinstalēts, tad tas radīs papildus, iespējams nevajadzīgu, noslodzi uz servera. Domāju šoreiz tā nebūtu problēma, bet labāk uzreiz iemācīties konfigurēt visu optimāli. Esmu diezgan daudz informācijas izpētījis, ko atradu internetā, bet parasti tā ir atsevišķi par katru no rīkiem, nesanāca atrast ko tādu apkopotu par šiem jautājumiem, tāpēc būšu pateicīgs, ja kāds varēs padalīties ar literatūras avotiem. Maksas literatūra arī derēs, būs labi latviešu, krievu un angļu valodā. Paldies!

Rindu skaits nebūs tas īstais un labais novērtējums programmētāja darbam. Tik pat labi var strādāt pie ļoti sarežģīta algoritma ar sarežģītiem matemātiskiem aprēķiniem, kuram būs tās pašas 40 rindiņas un pie kura būs jāstrādā nedēļa vai pat vairāk, lai viņš precīzi strādātu, īpaši tas jau ir tad kad domā kaut ko pavisam jaunu. Arī tik pat labi var izveidot objektu ar 40 mainīgiem un tā sākotnējo vērtību norādīšana vien jau aizņems 40 rindiņas, kas protams būs izdarāms daudz ātrāk par vienu dienu. Tā pat rindiņu skaits ir atkarīgs no programmētāja stila, kā viņš raksta kodu, piemēram es ļoti reti izmantoju if vietā "condition ? ture : false" un arī izpildāmo darbību pēc if vienmēr rakstu jaunā rindiņā. Tas tā tikai piemēram.

F3llony, paldies par atbildi. Jā, būs kaut kas līdzīgs arī jādara. Webmina ports netiek pāradresēts uz routera, tāpēc pieejams tikai lokālajā tīklā.

Marrtins, paldies par atbildi. Laikam tad daļēji varēs ignorēt to zombiju. Jāslēdz ārā webmins, kad viņu nevajag un jāsūta e-mails par zombijiem kad kāds zombijs aizkavējas uz ilgāku laiku. Vismaz liekās tā būs sakarīgi.

Sveiki tautieši! Nesen uzinstalēju tādu servera monitorēšanas rīku kā collectd. Viss sanāca, viss strādā, bet nu tagad saskāros ar tādu problēmu kā Zombie processes. Būtībā nav tā ka kāds zombijs parādītos un visu laiku paliktu, līdz viņu nokillo, bet parādās ik pa laikam uz ļoti īsu brīdi. To pamanīju collectd "Processes" grafikā. Pēc kāda laiciņa noskaidroju ka tas notiek tikai tad, kad ir palaists webmin, tad arī sanāca noķert to zombiju arī ar ps utilītu. Tālāk atbilstošās rindiņas no ps: 1 S 0 4070 1 0 80 0 - 16497 poll_s ? 00:00:00 miniserv.pl 1 Z 0 10276 4070 1 80 0 - 0 exit ? 00:00:00 /usr/libexec/we <defunct> Nokonfigurēju collectd, lai rāda papildus statistiku arī webmin serverim, izskatās ka zombiju parādīšanās, nu vismaz biežums, apmēram sakrīt ar webmin procesa pagefaultiem. Tālāk attēli: Procesi Webmin PageFaults Tas viss protams izskatās pēc webmin buga, bet jautājums ir tāds, vai tas ir normāli, ja sāk veidoties zombiji, kas ļoti ātri pazūd? Vai to var ignorēt? Es gribu to noskaidrot, tāpēc ka nezinu tagad kā pareizāk sakonfigurēt brīdinājumu sūtīšanu uz e-mailiem. Piemēram, par vietu uz cietajiem diskiem viss ir skaidrs, kad tās paliek pārāk maz ir jāsūta brīdinājums. Taču par zombijiem tagad es te mazliet aizdomājos, pirms es saskāros ar šo webmin brīnumu, man bija doma sūtīt brīdinājumu tiklīdz parādās kāds zombijs... Vēl pie reizes jautājums par pašu collectd, ja nu kāds to izmanto. Vai ir sanācis atrast labu dokumentāciju tieši collectd moduļiem? Pašam collectd dokumentācija ir laba, bet moduļi gan nav īsti labi aprakstīti, ne viņu mājas lapā, ne man lappusēs. Tas viss kā viņus nokonfigurēt un kā palaist viss ir smuki aprakstīts, bet domāju tieši par to kas tiek attēlots rezultātos. Piemēram, tam pašam "Processes" modulim attēlu rezultātos ir, piemēram, "87.8 Min", es īsti laikam nesaprotu, bet, ja tas ir procesu skaits, tad kāpēc tur ir daļskaitlis? Pie vidējām vērtībām es vēl to saprotu, bet pie Min, Max un Last, gan nesaprotu kāpēc varētu būt daļskaitļi. Vēl arī nesaprotu ko nozīmē mazais "m" burts pie vērtībām, piemēram "9.8m Avg". Kāpēc dažām vērtībām viņš ir un dažām nav. Katram grafikam ir protams savas neskaidrībās, tāpēc gribētos atrast kādu plašāku dokumentāciju par šo visu. Vēl jautājums, vai kādam ir kādas rekomendācijas par brīdinājumu sūtīšanu uz e-mailiem, es domāju tieši pie kādiem nosacījumiem sūtīt brīdinājumu? Šos jautājumus ierakstīju arī linuxquestions.org un webmin forumos, bet izskatās ka tur nesanāks atrast atbildes, tāpēc rakstu šeit. http://www.linuxquestions.org/questions/showthread.php?p=4830070 http://sourceforge.net/projects/webadmin/forums/forum/600155/topic/6200975 Paldies jau iepriekš!

Ieleja, izskatās ka tajā saitē ko iedevi teorija ir uz to pusi, vienīgi tā ātri izlasot neizpratu visu, nav arī domu kā to attiecināt uz FTP, bet papētīšu sīkāk. Vēlreiz paldies!

Ieleja, paldies par linku, apskatīšos. Īstenībā tur ir tas galvenais jautājums, vai tajā ir tā problēma? :) Kā jau teicu diezgan bieži, ieskaitot vsftpd dokumentāciju, tiek ieteikts neizmantot chroot ar rakstāmu home katalogu, bet kā tieši tas ietekmē drošību, nekur nav aprakstīts, te domāju tieši saistībā ar FTP serveriem, būtībā jebkādiem, ne tikai vsftpd, jo bugs ir (bija) glibc. Vienīgais daudz maz sakarīgais ko atradu, ka varot pie kaut kādiem nosacījumiem serverim iesmērēt savu konfigurācijas failu, bet kā tieši un vai tikai FTP konfigurāciju, tā arī neatradu. Zināmā mērā to varētu uzskatīt kā root pieejas ieguvi. Domāju ar to būs viss labi, jo lietotāji diez vai būs ieinteresēti kādam atdot savu paroli. Nebūs šoreiz īstā pieeja, jo, kā jau teicu, bugs ir (bija) glibc, lai gan tīri teorētiski varētu rakstīt FTP serveri, kam lietotāju lockošana ir realizēta ne caur chroot, bet nu par šādas idejas lietderību jau visi saprot ko varētu pateikt. :) Piekrītu, bet dažreiz ir jātaisa tā kā vajag sataisīt, kā grib priekšniecība, klients utt., nevis kā vieglāk administrēt (un iespējams arī pareizāk). Īpaši, ja jau ir kaudze FTP serveru, kuri ir realizēti ar lockotiem lietotājiem un rakstāmu root folderi, īpaši jau uz windows serveriem, jo tur nav tāda chroot par ko domāt. Tātad, būs vienkāršs jautājums, kāpēc citiem var un mums nevar? Tas kas man tagad interesē, ir problēmas būtība. Kā sataisīt jau risinājumi ir, bet nepatīk kaut ko darīt ja ir kādi drošības brīdinājumi, nenoskaidrojot par ko un kāpēc tie ir.

Paldies par atbildi. Īsti neder, jo tie visi FTP folderi iekšēji uzņēmumā ir pieejami caur parasto windows šāri, kā jau minēju sākumā, tā ir sanācis ka visi tie dati glabājās uz windowsīgā failu servera un tur noteikti kāds aizmirsīs aiziet uz uploads fodleri, vai sajauks vēl kaut ko. Ieskaidrot tiem kas pievienosies pa FTP, lai apskatās root katalogu, ja neatrod failu ir vēl sarežģītāk, jo gadās tādi, kas vispār FTP neprot lietot un tur jābūt priecīgam ka vismaz to ieskaidro. Nu vienkārši runājot visādas šāda veida apiešanas metodes radīs papildus sarežģījumus un agri vai vēlu kāds brīnīsies kur ir faili, nu tāpēc arī priekšniecībai varētu tā visa ķīmija nepatikt. Nākošā problēma būs protams tas ka tie visi folderi tiek mountēti no windows šārēm un tur atkal būtu jādomā kā labāk taisīt home folderi ar read only, nezinu vai var izmantot unix permissions un vai tās paliks pēc servera pārstartēšanas, neesmu to visu izpētījis, jo primārais tomēr ir sataisīt normālu home folderi ar atļauju rakstīt tajā. Kā jau teicu, ir vairākas pieejas kā to sataisīt un man tās ir zināmas, bet jautājums vēl joprojām paliek tas pats, vai ir droši izmantot rakstāmu mājas folderi ar chroot, ja leitotājam nav shell pieejas? :) Cik īsti nopietnas ir tās potenciālās drošības ievainojamības? Jo sanāk ka visi brīdina, pat manuāļos, par ievainojamībām, bet neviens īsti nepaskaidro kā tieši un kādai konfigurācijai jābūt, lai tās izmantotu.

Laikam neizteicos īsti precīzi. Visumā sanāk pievienoties FTP serverim, ja izmanto allow_writeable_chroot=YES bet noklusēti šī opcija ir izslēgta drošības apsvērumu dēļ, jo vsftpd ražotāji uzskata ka tas ir potenciāli nedroši, ja lietotāji tiek chroototi home folderī un tam ir rakstīšanas tiesības, tikai home folderim, apakšfolderi tad var būt ar rakstīšanas tiesībām, piemēram folderis upload. Dažviet var atrast informāciju kā to apiet un kāpēc tas ir, bet nekur nav konkrēti aprakstīts potenciālais drošības bugs. Piemēram šeit, ieskaitot komentārus: http://www.benscobie...t-inside-chroot vai arī šeit (pirmais komentārs): http://www.opennet.r...shtml?num=32459 bet šeit tiek rekomendēts tieši neizmantot home folderi ar rakstīšanas tiesībām. Direktīva local_root arī redirektēs lietotāju uz cit direktoriju, no man vsftpd.conf: local_root This option represents a directory which vsftpd will try to change into after a local (i.e. non-anonymous) login. Failure is silently ignored. Default: (none) bet vajadzētu panākt to, lai lietotājs paliek savā mājas folderī, nekur augstāk netiek un uzreiz patiešo tur var kaut ko rakstīt, bez visādiem upload folderiem. Vienīgais kā sanāca ir izmantojot: allow_writeable_chroot=YES bet jautājums ir, vai tas ir pietiekami droši, ja diezgan daudzās pamācībās, ieskaitot vsftpd dokumentācijā, to darīt nerekomendē?

Laba diena! Nevarēju īsti izdomāt kur šo rakstīt, pie drošības vai serveriem, bet tā kā vairāk saistīts ar serveriem, tad izdomāju ka labāk šeit. Tātad gribēju pajautāt, vai kāds ir pētījis un kaut ko sakarīgu atradis saistībā ar FTPd lietotāju ierobežošanu mājas direktorijā, ar chroot palīdzību, un drošību? Šis jautājums man radās pēc tā kā sakonfigurējot vsftpd ar lietotāju lockošanu mājas folderī, serveris pie savienojuma sāka rādīt kļūdu, ka nepieļauj savienojumus, ja tiek izmantots chroot un mājas folderim ir rakstīšanas tiesības. Salīdzinoši ātri atradu arī risinājumu, vsftpd ir opcija allow_writeable_chroot=YES kas ļauj noņemt šo ierobežojumu. Taču sākot meklēt iemeslus, kāpēc noklusēti nav pieļauta rakstīšana mājas folderī, sanāca atrast ka tas ir drošības apsvērumu dēļ, jo, ja nemaldos, 2009. gadā tika atrasta potenciāla ievainojamība glibc bibliotēkā, kas nekorekti apstrādājot chroot vidi var nolasīt, piemēram, FTP lietotāja mājas folderī ievietotu ~/etc/myconfig.conf, nu kaut kā tā, sakarīgu informāciju patiešām nesanāca atrast, ne kā tieši ievainojamība darbojas, ne kā to izmantot ar FTP serveriem. Iespējams, ka to nevar izmantot, ja nav shell pieeja FTP lietotājiem, bet nekur apstiprinājumu tam neatradu. Nesanāca arī sameklēt informāciju par to vai tā ievainojamība tagad ir izlabota. Domāju ka ir, jo diezgan daudz laika ir pagājis, kopš viņa ir atrasta, bet tad nav skaidrs, kāpēc vsftpd tomēr noklusēti neļauj mājas folderi veidot ar rakstīšanas tiesībām, iespējams uzskata ka chroot ar rakstīšanai atļautu mājas folderi potenciāli nav ļoti drošs, bet nu īsti nezinu. Vēl viena no alternatīvām ir taisīt root folderi kā read only un iekšā likt vēl vienu folderi, piemēram, upload. Taču tas nebūtu labākais risinājums, jo dažiem lietotājiem ir sarežģīti paskaidrot kā vispār lietot FTP, kur nu vēl skaidrot par kaut kādiem read only un upload folderiem. Kā arī tas varētu būt mazliet sarežģīti, jo paši lietotāju folderi atrodas uz windows servera un tiek mountēti kā tīkla šāres, tāpēc tur būtu jādomā kā to sataisīt, ka tikai home folderos ir tikai lasīšana un apakšfolderos ir arī rakstīšana. Ierakstīju šo jautājumu arī linuxquestions.org mājas lapā: http://www.linuxquestions.org/questions/linux-security-4/vsftpd-and-chroot-4175431314 taču nesanāca atrast atbildi arī tur. Tātad jautājums, vai kādam ir sanācis atrast kādu sakarīgāku informāciju par šo? Izmantoju: Slackware 14, glibc 2.15, vsftpd 3.0.2. Jau iepriekš paldies!

Ja nemaldos, to sauca par kopu reizināšanu.

Nu skaidrs. Nu nezinu, pagaidām palikšu pie vaicājumiem, iespējams kaut kad vajadzēs izpētīt kādu ORM.

Neiešu strīdēties, jo neesmu viņus izmantojis, bet ja tā ir, tas ir vēl viens trūkums. Piemēram, ja ir tabulā 30 - 50 lauciņi un man vajag tikai lietotāja vārdu, vai es varētu kaut kā izgūt tikai vārdus, nevis visu tabulu, īpaši ja ir tūkstošiem rindiņu?

DaGrevis, lietojums nesastāv tikai no tik vienkāršiem vaicājumiem. :) Pat ja arī tā būtu ar pārskatāmību es domāju to, ka vaicājumu redz ļoti tuvu tam kāds tas tiks izpildīts. Pat tādā piemērā kā Tu parādīji man labāk, lai es redzu reālu vaicājumu, kāds tas būs. Teiksim ja Tu būtu pierakstījis tikai to daļu 'User(9999)', es nekādi nesaprastu ka vaicājums pieprasa visus lauciņus priekš lietotāja ar id 9999, toties no sql vaicājuma es to zinu.

Ērtāk un pārskatāmāk uzrakstīt vaicājumu. :) Personīgi mans viedoklis.