Sparse image készítése

dd if=/dev/zero of=/path/to/1.img bs=1 count=0 seek=100G
losetup /dev/loop0 /path/to/1.img
mkfs.jfs /dev/loop0
mount /dev/loop0 /tmp/uu
df -h | grep /tmp/uu

Mikor jöhet ez jól? Pl. akkor, ha csillió file-t akarsz létrehozni, de a filerendszered már kész van, és kevés rajta az inode. Az ext4 pl. a formázás (azaz az mkfs.ext4 futtatása) után már nem teszi lehetővé az inode-ok számának módosítását.

3-2-1 Backup: The Rule For Recovery

Doug Hazelman ugyanezzel a címmel írt egy cikket a fenti szabályról: http://www.networkcomputing.com/storage/3-2-1-backup-rule-recovery/108368175

A 3-2-1 szabály talán a legfontosabb az adatok biztonsága szempontjából. Röviden azt mondja, hogy egy cégnek 3 példányban kell az adatait tárolnia, 2 különböző adathordozón, amiből az egyik egy másik helyszínen van.

A cikk megemlíti a Pixar esetét, amelyik majdnem elveszítette a Toy Story 2-t egy ügyetlen parancs és a nem működő mentés miatt. A Pixar csak azért menekült meg, mert valakinek megvolt a film az otthoni pc-jén.

Aztán Ohio államban valaki hazavitte a szalagot, amivel ugyan teljesült az ‘1’, csakhogy betörttek a lakásába, és elvitték a mentést is, amin rajta volt 64000 állami alkalmazott személyes adata, pl. igazolvány számok, stb.

Az NTP Software cikke megemlíti Peter Krogh nevét, akitől származik a 3-2-1 szabály. Szerinte 2 féle ember van: akinél már tönkrement a storage, és akinél még csak fog tönkre menni.

Az email archiválás kapcsán említette valaki, hogy “üzletileg nem elfogadható a levelek összevissza tárolása, elkülönítése, local archive meg stb bohóckodás.“, meg hogy jól vannak a levelek a mail szerveren.

Ez nyilvánvalóan nem felel meg a 3-2-1 szabálynak, és bizonyára nem véletlen, hogy tőlünk nyugatabbra konkrétan jogszabály írja elő (FRCP, SOX, …), hogy mely ipari szereplőknek meddig kell archiválni a leveleiket, hogy meglegyen a compliance.

Arról nem is beszélve,hogy ha pedig majd egyszer megborul a mail szerver alatt a storage (Krogh szerint ez csak idő kérdése), akkor lesz majd ‘fun’. De nem is kell hardware hiba, annyi is elég a bajhoz, ha valaki véletlenül (vagy éppen szándékosan) töröl a levelekből.

Az email archiválás – főleg ha egy 3. fél végzi – akkor védelmet nyújthat ez ellen is.

 

roundcube login failure after php upgrade to 5.6.x

I’ve just upgraded php to 5.6.x, and I couldn’t login to roundcube any more.

Since I use a self signed certificate I’ve added the following fix to config/config.inc.php:


$config['imap_conn_options'] = array(
'ssl' => array(
'verify_peer' => false,
'verify_peer_name' => false
),
);

Credits: https://bbs.archlinux.org/viewtopic.php?id=187063

 

 

The real cost of spam

Spam costs a lot: to us regular users. A nice article about the cost we have to pay in order to defend against spam.

The cost vectors (according to the article):

– antispam technology

Most companies deploy additional servers to filter spam. Some also buy commercial software to perform spam filtering. It needs staff to manage it, and all of these costs money.

– lost productivity

Spam wastes your time. It needs some attention to handle it. Note that “deleting messages, however, turns out to be the most expensive spam strategy. The average employee at companies that delete spam messages loses an average of 7.3 minutes per week looking for lost legitimate messages.”

– wasted storage

A usual method is to move spam emails to a quarantine. It consumes disk space, so you need additional storage capacity, and enterprise grade storage still costs.

– intangible costs

“Spam has a broader economic impact as well, hitting many businesses and nations that are least able to bear the burden. Consider Nigeria, for example. Nucleus Research noted that while fraud and corruption have been rampant in Nigeria for some time, the country may be forever kept in the digital darkness because of the volume of deceptive email sent by local spammers. The research firm noted that most spam filters block any mail with “Nigeria” in the title or text, effectively keeping anyone communicating with, from, to or about Nigeria from doing it via email.”

Deploying CoreOS OVA on VMware

Deploy the vmware ova

Download the OVA image from Core OS website, and deploy it to VMware using vsphere client, etc.

When you boot the VM, you won’t be able to login, unless you provide coreos.autologin=tty1 as a kernel parameter to grub. If you do so, then you’ll be auto logged in as user core. Type sudo bash to get the root prompt necessary for the initial setup.

Read more at http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2109161

Configure networking

Create /etc/systemd/network/static.network, add the following, and finally reboot:


[Network]
Address=192.168.1.2
Gateway=192.168.1.1
DNS=192.168.1.100 192.168.1.101

Read more at https://www.brianchristner.io/how-to-install-and-configure-coreos-inside-vmware/

Setup ssh acccess

Edit /usr/share/oem/cloud-config.yml, and add your ssh public key, eg.


ssh_authorized_keys:
- ssh-dss AAAAB3NzaC1kc3MAAAEBAOm5s8yJIl1ZnaqQU93f.....

Then validate the settings:


coreos-cloudinit --validate --from-file /usr/share/oem/cloud-config.yml

If everything goes right, then apply settings:


coreos-cloudinit --from-file /usr/share/oem/cloud-config.yml

Now you may ssh to the host using your private ssh key as user core, eg.


ssh -i /path/to/ssh.key -l core 192.168.1.2

You may want to setup etcd (version 2)


etcd2:
# generate a new token for each unique cluster from https://discovery.etcd.io/new?size=3
# specify the initial size of your cluster with ?size=X
discovery: https://discovery.etcd.io/THE_VALUE_OF_THE_GENERATED_TOKEN

# multi-region and multi-cloud deployments need to use $public_ipv4
advertise-client-urls: http://0.0.0.0:2379
initial-advertise-peer-urls: http://0.0.0.0:2380
# listen on both the official ports and the legacy ports
# legacy ports can be omitted if your application doesn't depend on them
listen-client-urls: http://0.0.0.0:2379
listen-peer-urls: http://0.0.0.0:2380

Recommended reading:

Cloud config docs
Using CoreOS

Pár érdekesség stub-okat használó email archívumból migrálás során

Chris McVeen írása Addressing Email Archive Shortcuts/Stubs when Migrating címmel, ami néhány váratlan meglepire készít fel, hogy ha migrálni akarsz egy olyan email archívumból, ami stub-okat (=pointerek a levélből kivágott és máshol található mellékletekre) használ.

A migráció során ezeket a stub-okat helyre kell állítani. Az egyik ilyen gotcha a művelet során az, hogy pl. a Microsoft Exchange egy új Message-ID-t fog generálni, ha letörlöd a stub-ot tartalmazó levelet, majd lecseréled a helyreállított levéllel. Az új Message-ID pedig gondot okozhat a levelezőklienseknél. Ennél jobb a stub rehidratálás, amelynek során nem törlöd az archivált levelet, hanem a stubbing során eltávolított adatokat helyreállítod. Ebben az esetben megmarad az eredeti Message-ID.

Tavmunka.net – csak óvatosan!

Ne kérdezd, hol jártam, amikor egy érdekes cikket találtam a neten. A tavmunka.net (mint a neve is sugallja) távmunkásokat közvetít ki. Eddig jó. Ami már nem annyira jó, hogy ezen a weboldalon a munkavállalók személyes adatait is böngészni lehet(ett).

“Az oldal egy legördülő menüben, email címek alapján teszi kereshetővé a munkavállalók adatlapjait. Az adatlapok sok esetben tartalmazzák az érintett nevét, lakcímét, adószámát, bankszámlaszámát, mobil számát, email címét, az oldalon használt ügyfélkódját, az ehhez tartozó jelszavát és egyéb a munkavégzéshez kapcsolódó adatokat.”

Az eset súlyosságát mutatja, hogy a hírek szerint több tízezer személy adata érhető el ilyen módon.

“Az oldal üzemeltetője a közzétett információk alapján a 2012-ben bejegyzett Telejob Ltd. (West Sussex – Egyesült Királyság). Vezetője Csernák Sándor, aki a tavmunka.net domain nevet magánszemélyként regisztrálta és aki a ma már kényszertörlési eljárás alatt lévő TELEJOB Kereskedelmi Korlátolt Felelősségű Társaságnak is egyedüli tagja és vezető tisztségviselője.”

A NAIH az ügyben már vizsgálatot indított és megkereste a cég ügyvezetőjét.”

A neten utána keresve a tavmunka.net-nek azért lehet találni negatív kritikákat is:

http://itcafe.hu/tema/tavmunka_net_ki_mit_tud_a_dologrol/hsz_1-50.html
http://munkahelyiterror.blog.hu/2012/05/29/a_tavmunka_net_is_lehuzza_a_dolgozni_vagyokat
https://www.facebook.com/listazz/posts/517447491623976

Végezetül egy interjú a cégvezetővel, ahol megmagyarázza: http://www.fovarosi-hirhatar.hu/hir/tavmunkanet-interju-a-cegvezetovel. Az én bizalmam mindenesetre nem sikerült elnyernie.

Ha a spam fénykép lenne

Egy spanyol fényképész összegyűjtötte a neki küldött levélszemetet, és olyan fényképeket készített belőlük, amelyek bemutatják a feladókat. Az alábbiakhoz hasonló képek születtek, a képek alatt a spam szövege:

This image was inspired by an email supposedly sent by the grieving widow of a Russian oligarch, her life in danger due to her inheritance.

This lawyer from Nigeria is looking to split a $3.5 million stash: 50% for him and 45% for you – minus 5% for expenses, of course.

Forrás: Here’s what it might look like if your spam emails came to life

A túlélésért küzdenek az amerikai kuponoldalak – hátha ha a magyar piac is tisztulni fog egy kicsit

Az Indexen jelent meg A túlélésért küzdenek az amerikai kuponoldalak címmel egy cikk, ami szerint nem kicsi kakában vannak a tengerentúli kuponos cégek.

Az induláskor a kiskereskedelmi modellt szerették volna megváltoztatni, ami olyan sikeres volt, hogy mára a túlélésért küzdenek. Pl. a Groupon részvényeinek értéke az előző 1 évben 90%-ot esett. Hogy ez nem Groupon-specifikus probléma, azt az is mutatja, hogy “nyilvánvalóvá vált, hogy a közösségi vásárlós oldalak üzleti modellje életképtelen. Ezt már többször jelezték szakértők, először még a Groupon tőzsdére lépése előtt. Akkor még senki nem hallgatott rájuk, pedig az idő őket igazolta.”

Ez az egész abból a szempontból érdekes most, hogy a szörnyen kicsi magyar piacon is gombamód szaporodnak a kuponos oldalak. Van pár nagyobb szereplő, és vannak a ‘futottak még’ kategóriába eső kupontemetők, akik mindent megtesznek (=értsd: spammelnek, ahogy a csövön kifér), hogy a felszínen maradjanak.

“A Groupon és a hasonló kuponoldalak azzal érvelnek a modell életképessége mellett, hogy az mindenkinek megéri: a vásárlónak azért, mert féláron kap szolgáltatásokat, a kereskedőnek pedig azért, mert sok vevője vagy ügyfele lesz. Az elemzői kutatások azonban ennek az ellenkezőjét bizonyítják, az akciók lezárultával a kereskedők több mint harmada nem akar még egyszer részt venni újabb Groupon-ajánlatokban.”

Ezt mondjuk nem is csodálom, főleg Magyarországon nem, ahol az ember 5 Ft-ért a másik boltba megy.

“Egy a Reuters által idézett kutatás szerint a megkérdezett kereskedők 32 százaléka veszített az üzleten, és 40 százalék mondta azt, hogy a kuponoldalakkal való szövetkezés kevésbé hatékony, mint más marketingtevékenység. A legfőbb indok, amit emlegetnek, hogy túl magasak a cég által kért közvetítői díjak, és nagyon kevés a visszatérő vásárló.”

Hogy mennyiért közvetítenek a hazai kuponos cégek, azt nem tudom, de arra bátran mernék fogadni, hogy a visszatérő vásárlók száma itt is nagyon kevés. Márpedig pont a visszatérő (és aztán már teljes árat megfizető) vásárlók miatt érné meg a hazai cégeknek – ha így aligha éri meg.

A cikk szerint az egyik hazai kuponos oldal már viszonylag az elején egy más modellt választott, hogy elkerülje a Groupon sorsát. Azok a kis szereplők – pl. Kupon Diszkont, Kupon Bónusz, KuponGroup, Alkuguru – akik spamben tukmálják a kuponjaikat (az egyik kuponos spammer pl. nem szégyellt 6(!) termékkel kiállni a standra) – aligha kerülhetik el a sorsukat: a jól megérdemelt süllyesztőt. Amelyik pedig bukik, az legalább a spammelést is abbahagyja.

Apropó spam: érdekes, hogy a nagyobb, a hírnevükre valamit is adó kuponos oldalak nem spammelnek, ők hallottak már a feliratkozás megerősítéséről. Ezzel ellentétben a kis, amatőr, futottak még kuponos cégek, amelyekről ordít a gagyiság, számára a marketing egyet jelent a spammeléssel. Talán nem tévedek nagyot, ha azt jósolom, hogy a kutya sem vog utánuk vonyítani, amikor eltűnnek a ködben.