Tuesday, 4 August 2015

Ansible: Using multiple tags and untagged tag together

I have lots of Ansible playbooks with many roles in each. However when you are installing different minor version of the same software stack, there are only minor differences between the steps. In this case it does not make much sense to "copy paste" the whole role so I just wanted to use tags. I wanted to use untagged tasks as common tasks and tagged tasks for version specific tasks. To make it clear here is an example. If you have a long os related role which does ssh config, web config, database install and creation and many more but sometimes you need java-6 or java-7 it is easy to add task and tag those according to this. Than my theory was that I can run
ansible-playbook --tags=untagged,java6
to install the stack with java6 and
ansible-playbook --tags=untagged,java7
to install same stack with java7. However this does not work.

I have checked the Ansible source code and found why it is not working. Since I was not sure if this is a bug or by design I have opened a issue and described the problem.

Brian Coca was kind to answer quickly and as you can read he wrote this is by design but he was also kind to consider it as a feature request. Hope will be accepted. However if you need this modified behaviour now you can either check the issue or read the solution below.

Ansible 1.9


The corresponding code part is the tasks_to_run_in_play() function in playbook/__init__.py

Original code:
elif 'untagged' in self.only_tags:
    if task_set == u:
        should_run = True

Proposed fix:
elif 'untagged' in self.only_tags and task_set == u:
    should_run = True

Friday, 26 June 2015

Hortonworks HDP 2 moving master componenst to other nodes

In a need to decommission a node from a Hadoop cluster based on HDP 2.2.4.2 I have realised that Ambari 2.0 delivered with HDP 2.2.4.2 can not move History Server and Falcon Server master components to another node. Simply the functionality is missing. I could use the Ambari web UI for every other service I wanted to move but not these two.

So looking around I found a this mail

which I am summarising in the below command set.

  • Stop Falcon Server and History Server via the Ambari UI.
  • Execute below commands and do not forget to specify values for the first five lines :)
    AMBARI_SERVER_HOST=
    CLUSTERNAME=mycluster
    HOSTNAME=
    TARGET_HOSTNAME=
    PASS=

    curl -i -u admin:${PASS} -H 'X-Requested-By: ambari' -X DELETE http://${AMBARI_SERVER_HOST}:8080/api/v1/clusters/${CLUSTERNAME}/hosts/${HOSTNAME}/host_components/HISTORYSERVER

    curl -i -u admin:${PASS} -H 'X-Requested-By: ambari' -X POST -d'{"HostRoles":{"component_name":"HISTORYSERVER"}}' http://${AMBARI_SERVER_HOST}:8080/api/v1/clusters/${CLUSTERNAME}/hosts/${TARGET_HOSTNAME}/host_components

    curl -i -u admin:${PASS} -H 'X-Requested-By: ambari' -X DELETE http://${AMBARI_SERVER_HOST}:8080/api/v1/clusters/${CLUSTERNAME}/hosts/${HOSTNAME}/host_components/FALCON_SERVER

    curl -i -u admin:${PASS} -H 'X-Requested-By: ambari' -X POST -d'{"HostRoles":{"component_name":"FALCON_SERVER"}}' http://${AMBARI_SERVER_HOST}:8080/api/v1/clusters/${CLUSTERNAME}/hosts/${TARGET_HOSTNAME}/host_components
  • After the commands have been executed go to the Ambari UI and click Re-Install for the services on the new host.
  • As noted in the e-mail please update the values of mapreduce.jobhistory.address and mapreduce.jobhistory.webapp.address of Mapreduce2 via the Ambari UI.
  • Please also update *.broker.url under Falcon -> Config -> Falcon startup.properties
  • When installation finished start the services.

Sunday, 24 May 2015

Ansible ec2 module "region must be specified" issue

Some month ago I made an Ansible based autoinstall for Hortonwork's HDP 2.2.
Since HDP 2.2.4.2 is out I wanted to update my install process and test how it works. However I had to realize that my previously working ansible playbooks are failing with an error message.

TASK: [Launching Ambari instance] *********************************************
failed: [localhost] => {"failed": true}
msg: region must be specified

FATAL: all hosts have already failed -- aborting

First I have checked my ansible, eucalyptus and boto config. However everything was fine. So I have checked the code of the ec2 module of ansible and found the error message in the source.

# tail -n +1205 /usr/share/pyshared/ansible/modules/core/cloud/amazon/ec2.py|head -17

ec2 = ec2_connect(module)

ec2_url, aws_access_key, aws_secret_key, region = get_ec2_creds(module)

if region:
try:
vpc = boto.vpc.connect_to_region(
region,
aws_access_key_id=aws_access_key,
aws_secret_access_key=aws_secret_key
)
except boto.exception.NoAuthHandlerFound, e:
module.fail_json(msg = str(e))
else:
module.fail_json(msg="region must be specified")

The code shows if region is not specified you get this error message and actually this is what the message itself writes.

BUT WHY DO YOU NEED A REGION? IT WAS NOT NECESSARY BEFORE! SEEMS TO BE A BUG!!!

After checking Ansible bugs I have found a bug describing my problem. One of the commenter also found the same code part suspicious. So I have modified it a bit to avoid the vpc related issue and after the modification all my playbooks started to work fine again.
1207c1207
< 
---
>     vpc=None
1219,1220c1219,1220
<     else:
<         module.fail_json(msg="region must be specified")
---
>     #else:
>     #    module.fail_json(msg="region must be specified")
1237d1236
< 

Side-by-side diff
ec2 = ec2_connect(module)                                       ec2 = ec2_connect(module)
                                                              |     vpc=None
    ec2_url, aws_access_key, aws_secret_key, region = get_ec2       ec2_url, aws_access_key, aws_secret_key, region = get_ec2

    if region:                                                      if region:
        try:                                                            try:
            vpc = boto.vpc.connect_to_region(                               vpc = boto.vpc.connect_to_region(
                region,                                                         region,
                aws_access_key_id=aws_access_key,                               aws_access_key_id=aws_access_key,
                aws_secret_access_key=aws_secret_key                            aws_secret_access_key=aws_secret_key
            )                                                               )
        except boto.exception.NoAuthHandlerFound, e:                    except boto.exception.NoAuthHandlerFound, e:
            module.fail_json(msg = str(e))                                  module.fail_json(msg = str(e))
    else:                                                     |     #else:
        module.fail_json(msg="region must be specified")      |     #    module.fail_json(msg="region must be specified")

Sunday, 8 February 2015

Google Now Launcher : No settings, no cards, not working anymore.

My Moto G 1st Gen runs Android 5.0.2 and I was using Google Now Launcher on top. It had been working fine for long but one day suddenly all my cards disappeared and search did not work anymore. The "Reminders" and the "Customize" menu items were inactive and trying to use "Settings" of Google Now Launcher just crashed.

Since Googling around did not reveal any exact solution but gave some hints here is what I have done at the end.

Please note: You will loose all your Home Screen and Google Now customizations!!!

So go to Settings - Apps and swipe to the "All" page. Search for and select "Google App".
 
First try "CLEAR CACHE".


If still not working select "MANAGE SPACE" and than try first "CLEAR GOOGLE SEARCH DATA". Still no luck? Select "CLEAR LAUNCHER DATA" but this is where you loose your customizations. Finally if none of the above was working you can select "CLEAR ALL DATA".

After this you might have to reconfigure Google Now and also you have to recreate your Home screen.

Friday, 16 January 2015

User based queue mapping for Capacity Scheduler

When I  started to use Capacity Scheduler hierarchical queue features on top of Hortonworks' HDP 2.0 I have immediately realized that I need automatic assignment of job to queue based on username.

Sounds easy and useful? Yes! But could not find any configuration parameter and example for that.

I found only references to use mapred.job.queuename config option. This can be configured in HIVE via set mapred.job.queuename=yourqueue or using -Dmapred.job.queuename=yourqueue as a hadoop command argument.

After some hours of unavailing googling I have checked the corresponding code part and have been shocked. This is available only since HADOOP-2.6 (HDP-2.2). Check YARN-2411 for details. According to the CHANGELOG this is a relatively new feature. So sadly this is not available to me until an upgrade.

:(

See below an example based on YARN-2411 to use it in Hadoop 2.6 or higher for Hortonworks HDP-2.2

1. user1 is mapped to queue1, group1 is mapped to queue2:

yarn.scheduler.capacity.queue-mappings-override.enable=true
yarn.scheduler.capacity.queue-mappings=u:user1:queue1,g:group1:queue2

2. To map users to queues with the same name as the user:

yarn.scheduler.capacity.queue-mappings-override.enable=true
yarn.scheduler.capacity.queue-mappings=u:%user:%user


Update: As a workaround I have configured the default queue to have very low 10% capacity with the possibility to use even 100% and created another queue which has 90% capacity (up to 100%) and can be used only by a special user. Also enabled ProportionalCapacityPreemptionPolicy so the system will kill over allocated resources from default queue in case prio queue needs those.

Example config:
yarn.resourcemanager.monitor.capacity.preemption.max_wait_before_kill=20000
yarn.resourcemanager.monitor.capacity.preemption.monitoring_interval=10000
yarn.resourcemanager.monitor.capacity.preemption.total_preemption_per_round=0.1
yarn.resourcemanager.scheduler.monitor.enable=true
yarn.resourcemanager.scheduler.monitor.policies=org.apache.hadoop.yarn.server.resourcemanager.monitor.capacity.ProportionalCapacityPreemptionPolicy
yarn.scheduler.capacity.maximum-am-resource-percent=0.2
yarn.scheduler.capacity.maximum-applications=10000
yarn.scheduler.capacity.node-locality-delay=40
yarn.scheduler.capacity.root.acl_administer_jobs=*
yarn.scheduler.capacity.root.acl_administer_queue=*
yarn.scheduler.capacity.root.acl_submit_applications=*
yarn.scheduler.capacity.root.capacity=100
yarn.scheduler.capacity.root.default.acl_administer_jobs=*
yarn.scheduler.capacity.root.default.acl_submit_applications=*
yarn.scheduler.capacity.root.default.acl_submit_jobs=*
yarn.scheduler.capacity.root.default.capacity=10
yarn.scheduler.capacity.root.default.maximum-capacity=100
yarn.scheduler.capacity.root.default.state=RUNNING
yarn.scheduler.capacity.root.default.user-limit-factor=10
yarn.scheduler.capacity.root.prio.acl_submit_applications=specialuser
yarn.scheduler.capacity.root.prio.acl_submit_jobs=specialuser
yarn.scheduler.capacity.root.prio.capacity=90
yarn.scheduler.capacity.root.prio.maximum-capacity=100
yarn.scheduler.capacity.root.prio.state=RUNNING
yarn.scheduler.capacity.root.prio.user-limit-factor=10
yarn.scheduler.capacity.root.queues=default,prio

Thursday, 15 January 2015

Hortonworks Hadoop HDP 2.0 lost default capacity scheduler config

As a result of my fault, and also result of strange behaviour of Ambari UI, I have overwritten my default capacity scheduler configuration data on my Hadoop Hortonworks HDP 2.0 cluster. Looking around I have found the xml file containing the original value as
/var/lib/ambari-agent/cache/stacks/HDP/2.0._/services/YARN/configuration/capacity-scheduler.xml

However on the UI you need a properties file style format. Here it is.

yarn.scheduler.capacity.maximum-applications=10000
yarn.scheduler.capacity.maximum-am-resource-percent=0.2
yarn.scheduler.capacity.root.queues=default
yarn.scheduler.capacity.root.capacity=100
yarn.scheduler.capacity.root.default.capacity=100
yarn.scheduler.capacity.root.default.user-limit-factor=1
yarn.scheduler.capacity.root.default.maximum-capacity=100
yarn.scheduler.capacity.root.default.state=RUNNING
yarn.scheduler.capacity.root.default.acl_submit_jobs=*
yarn.scheduler.capacity.root.default.acl_administer_jobs=*
yarn.scheduler.capacity.root.acl_administer_queues=*
yarn.scheduler.capacity.root.unfunded.capacity=50

Thursday, 30 January 2014

Az NSA botrány ahogy én látom – A politikai szál


Az NSA botrány ahogy én látom – A politikai szál


„Horkanó zaj támadt belülről, aztán csönd lett”
A. A. Milne: Micimackó

Bevezetés

Hosszabb szünet után megint nekifutottam egy összefoglalónak. A szünetnek két fő oka volt. Az egyik, hogy mivel kiszivárogtatás folyik, meg kellett várni, amíg megint összegyűlik annyi információ, amiről már érdemes írni. Utólag be kell lássam, hogy túl sokáig vártam. A másik, hogy jó ideig inkább politikai színtéren zajlott a botrány, és bár nem azt mondom, hogy ez kevésbé lenne fontos, SŐT, de – bocsássátok meg nekem eme személyes megnyilvánulás – engem sokkal kevésbé érdekel ez a vonal és ezért nem is tértem ki erre az első összefoglalóban. Ettől függetlenül úgy gondolom, megérett az idő egy újabb összefoglalóra, és most, minden viszolygásom ellenére, az unalmas politikai vonalról olvashattok nem keveset, hogy utána majd megint a technikai dolgokra összpontosíthassunk.

A politikai vonal


Az első nemzetközi/külpolitikai jellegű botrány a még 2009-ben tartott G20-as sztori 2013.06.17-i kirobbantása volt. Mint dokumentumokkal igazolták, ennek keretében a britek a résztvevő országok magas rangú képviselőinek számítógépeit és mobiltelefonjait figyelték meg. A levelezésüket speciálisan erre a célra épített hozzáférési pontokon keresztül figyelték meg, és a rendelkezésre bocsátott gépekre pedig, biztos ami biztos keyloggert – billentyűzet leütés figyelő program – is telepítettek.
Megj. : Fontos ember ne használjon már mást mint a saját megbízható gépét!
Továbbá valamilyen módon, a küldöttek BlackBerry telefonjainak biztonságát megkerülve, el tudták olvasni az e-mailjeiket és megfigyelték a hívásaikat is. Az egész megfigyelés célja az volt, hogy előnyt biztosítsanak maguknak és az USA-nak a tárgyalások folyamán. Ez volt az első olyan kiszivárogtatott megfigyelési elem, amit már nyilvánvalóan nem lehet a terrorizmus elleni harccal magyarázni.

A politikai botrányvonal következő nagyobb híre az volt, amikor 2013.07.30-án kiderült, hogy az Amerikában lévő szövetséges európai nagykövetségek legtöbbjét is lehallgatják különböző módszerekkel.
Megj. : Érdekesség még, hogy minden nagykövetség minden irodájának megfigyelése külön kódnéven futott mint pl. : Blackfoot, Wabash, Bruneau, Hemlock, Powell, Klondyke. Ilyen téren is kreatívak voltak a fiúk az biztos.

Innentől csak címszavakban és linkekkel a politikai vonalról szóló általam fontosabbnak ítélt cikkek.

Politikai vonalon látok egy kis keveredést, illetve összemosást a különböző típusú megfigyelések között, amit szeretnék tisztázni.

Van ugye az eddig is ismert tömeges megfigyelés és van a célzott megfigyelés. Például Angela Merkel telefonjának megfigyelése célzott megfigyelés volt, ugyan úgy, ahogy a vezető politikusoké is. Sőt a politikai vonalon történő megfigyelések nagy része célzott volt. Míg a nem politikai vonalon tömeges típusú megfigyelések zajlottak a korábbi információk alapján.

A másik a technológiák összemosása. A klasszikus megfigyelési módszerek – poloskás, mikrofonos, rejtett kamerás vagy hasonló, de helyben lévő eszközzel történő megfigyelések – összemosása az új típusú – távoli szoftveres, vírusos, internetes, backdoor-os, exploit-os – megfigyelésekkel. Kicsit utána gondolva, valójában van összefüggés a két csoportosítás között. Ugyanis a klasszikus megfigyeléseket tömegesen kivitelezni nehéz lenne – legalábbis remélem. Ezért a tömeges megfigyelések az új típusú, míg a célzott megfigyelések a klasszikus típusú kategóriába esnek többnyire, azzal a kitétellel, hogy természetesen az új típusú technológiák alkalmasak a célzott megfigyelésre is. Ettől függetlenül szétválasztanám ezeket a következőkben.
Frissítés: A fenti rész írásakor még nem volt ismert pár később bemutatásra kerülő módszer. De azért nem javítottam ezt a fejezetet, hogy ezzel is be lehessen mutatni, mennyire meg kell változtatni a megszokott világképünket egy-egy új információ morzsa következtében.

Ennyi bevezető után lássuk mi a személyes véleményem a politikai megfigyelésekről.

A korábban ismertetett tömeges, új típusú technológiai megfigyelés szerintem minden törvényt és szokásjogot sért, és nem is lehet a jelenlegi jogi körülmények között törvényesen végrehajtani, míg a klasszikus megfigyelés – legalábbis elvileg – kivitelezhető törvényesen, illetve benne van a szokásjogban.

A politikusok klasszikus típusú lehallgatása nálam a „hivatalosan elfogadhatatlan de kicsit sem meglepő és amúgy hétköznapi” kategóriába esik. Ami viszont kérdésként felmerült bennem és pár cikk is utal rá, hogy ez a fajta tevékenység tipikusan nem NSA hatáskör, hanem amennyire én meg tudom ítélni inkább CIA.

Továbbá kérdezném, hogy például mit csináltak a megfigyelt államok saját titkosszolgálatai mindeközben? Miért engedték, hogy magas beosztású állami hivatalnokok lehallgatható telefonokat használjanak és gmail-es, yahoo-s, hotmail-es email címeket használjanak akár hivatalos levelezésre? Tényleg ennyire amatőrök voltak ezek a fontos pozícióban lévő emberek, és nem is volt senki, és semmi ami felnyitotta volna a szemüket? Utólag ugyan léptek és például lecserélték a telefonokat. De tényleg kellett egy botrány ehhez? Nem akarom elhinni.

Ezzel szemben a politikusok új típusú célzott megfigyelése – gondolok például VPN vagy egyéb titkosítások feltörésére, kormányzati szerverek feltörésére és gépek megfertőzésére – szerintem teljes mértékben elfogadhatatlan baráti országok között.

A politikai vonal természetesen nagyon fontos, mert ennek jelentős hatása lehet a nemzetközi politikára és a gazdaságra is. Mást ne mondjak például az előkészítés alatt álló Európai Unió és Egyesült Államok közötti kereskedelmi megállapodásra is lehet hatása, még akkor is, ha megakadályozni nem is foglya, de esetleg jó muníciót adhat az EU-nak. Viszont a tényleges politikai és gazdasági hatásokat szerintem majd csak egy következő Edward Snowden fogja megmutatni nekünk.

Frissítés: Ez szintén egy korábban megírt rész volt. Azóta azt hiszem kiderült, hogy bátran kijelenhetjük egy kis színjátékon kívül semmi nem történt és nem is fog. Angela Merkel-t a választásokban például még egy kicsit sem zavarta meg az eset. Azért mindenki eljátszotta a sértettet, meg odamondogatott a másiknak. Aztán csönd lett.


Obama beszéde az NSA reformjáról

FIGYELEM!!! HOSSZÚ ÉS MÉG A FENTINÉL IS UNALMASABB RÉSZ KÖVETKEZIK.
CSAK SAJÁT FELELŐSSÉGRE OLVASS TOVÁBB !!!

ÉN SZÓLTAM.


Jóval a fentiek megírása után 2014.01.17-én hangzott el Obama beszéde az NSA reformjáról. Szemezgessünk most még ebből, mintegy a politikai száll lezárásaként.

Ha nagyon röviden szeretném összefoglalni Obama az NSA reformjáról szóló beszédét azt írhatnám, hogy:
„blaah blaah blaah blaah blaah.
...
blaah blaah!
...
blaah blaah blaah blaah.

Thank you. God bless you. May God bless the United States of America. Thank you. (Applause.) Thank you. Thank you."

Na de komolyra fordítva, próbálok egy tömörebb fordítást, illetve ahol lehet összefoglalást írni a beszédről ami a maga 43 percével elég hosszúra sikeredett.

(Ha kihagynád a most következő hosszú és unalmas részt itt van a "végeredmény" röviden.)

Először egy hosszú történelmi áttekintő rész hallhattunk, amely azt volt hivatott nyomatékosítani, hogy a titkosszolgálatokra régóta szükség van és szükség lesz a jövőben is. Hivatkozott Obama az amerikai polgárháborúra, a második világháborúra, a vasfüggöny és a hidegháború időszakára is.
Megj.: Nem mintha nem értenék egyet azzal, hogy titkosszolgálatokra szükség van, de azért remélem mindenkinek feltűnt, hogy csupa háborús időszakra hivatkozott.

Ez után jött a beszéd félelem keltő rész.

Obama szerint Oroszország bukásával az USA-nak, mint az egyetlen megmaradt szuperhatalomnak, szüksége van a titkosszolgálati tevékenységének fokozására és technológiai modernizálására az egyre növekvő terrorfenyegetettség és a tömegpusztító fegyverek terjedése miatt. Nehezíti a helyzetüket, hogy a globalizáció és az internet elmossa a határokat, és ez lehetővé teszi bárki számára, hogy ezt jóra használja, de azt is, hogy irtózatos károkat okozzon. A megváltozott körülményekhez nem sikerült jogilag alkalmazkodniuk. Különösen az egyénileg vagy kis ideológiai csoportok által elkövetett terrorcselekmények megelőzéséhez szükséges törvénymódosítások hiányoznak.
Megj.: Ugye mindenki érti miért hangsúlyozzák pont ezt? Egyének. Minden egyes egyén veszélyforrás. Tehát mindenki az.

Majd jött a Jolly Joker 9/11 említése, amivel a megváltoztatott megfigyelési módszereket – értsd tömeges, bírói engedély nélkül végzett, mindenféle kommunikációra és pénzügyi tranzakcióra kiterjedő és a kapcsolatokat is feltérképező megfigyelési módszerek – és azok szükségességét indokolta. Természetesen mindezt, amennyire lehet, a jogi kereteknek megfelelően tették – amely jogi keretek, ahogy Obama is hangsúlyozta, amúgy is csak az amerikaiknak adnak némi védelmet, és a külföldieket úgy figyelik meg ahogy akarják. Tekintettel a rendkívül gyorsan fejlődő, az egész világon csak az USA-ban rendelkezésre álló technológiára, és az ezzel párhuzamosan a szolgálatra nehezedő nyomásra amit nem tudtak jogszabályokkal megfelelően követni, néha hibákat követtek el, és a hatékonyság oltárán fel kellett áldozniuk a jogkövető magatartást.

De a fentiek eredményeként több támadást is megelőztek és így ártatlanok életét mentették meg nem csak az USA-ban de szerte a világon mindenfelé.
Megj.: Bár érhető, hogy erről többet nem mondhat de azért ez így elég kevéssé meggyőző.
Mivel a fenyegetések nem fognak csökkenni a jövőben sem, ezért meg kell hozniuk a szükséges döntéseket, amelyekkel megvédhető az ország, fenntartható marad az ország vezető pozíciója, de garantálják az alkotmányban biztosított személyiségi és szabadságjogokat is. Ez a munka már elkezdődött, és hónapok óta széleskörű egyeztetéseket folytatnak. Látni kell azonban, hogy a digitális kommunikáció lehallgatása és a védelmének megkerülése nélkül nem lehetséges a terroristák leleplezése, a tőzsdét fenyegető rosszindulatú programok kiszűrése, a repülés irányító rendszerek megvédése és annak biztosítása, hogy a bankszámlánkról nem lopják el a pénzt.
Megj.: Ez a rész volt a félelem keltés 2.0.
Obama kiemelte, hogy más országok, olyanok is akik a Snowden dokumentumok megjelenésekkor meglepettnek mutatkoztak, a USA-éhoz hasonló módszerekkel próbálják megfigyelni az USA-t.

Mint mondta, nem véletlenül nem lehet iPhone és BlackBerry telefonokat használni a Fehér Ház biztonságos tanácstermében. Sérelmezte, hogy olyan országok kritizálják most hangosan az NSA-t, akik egyébként elismerik, hogy Amerikának, mint az egyetlen megmaradt szuperhatalomnak, kiemelt felelőssége van, és az NSA tevékenysége nélkülözhetetlen. Egyébként pedig ezek az országok is az NSA információira támaszkodnak a saját polgáraik megvédéséhez.

Azok akik az egyeztetéseken részt vettek belátták, hogy a magánszférát nem csak a hivatalok sértik meg, hanem azok a kisebb nagyobb vállalatok is akik kereskedelmi célból nyomon követik és analizálják a felhasználó szokásait, hogy így célzott reklámokat juttassanak el hozzájuk. Természetesen a kormányzati megfigyelésekre vonatkozó szabályoknak sokkal szigorúbbaknak kell lenniük, és nem elég ha ezeket a szabályokat csak bizalmi alapon kontrollálják, mivel már a múltban is történtek esetek, amikor ezzel a bizalommal visszaéltek. Ezért mindenképpen szükség van jogi korlátokra.
Megj. A magánszektor említésével nyilván relativizálni akart a hivatali adatgyűjtést. Azonban azt a fontos tényt elfelejtette megemlíteni, hogy a magánszektor szereplőinek nincs annyira átfogó képe a felhasználókról mint az NSA-nek, mivel ők csak a tőlük induló vagy a náluk végződő kommunikációkat figyelhetik - reméljük - nem pedig az összeset.

Ennyi felvezetés után lássuk milyen konkrét intézkedéseket jelentett be Obama.

1. Obama jóváhagyott egy elnöki direktívát, amely mind a külföldi mind a belföldi titkosszolgálati megfigyelésekre vonatkozó iránymutatásokat tartalmaz, és már figyelembe veszi nem csak a belső biztonsági követelményeket, hanem a szövetségesi, kereskedelmi és befektetési kapcsolatokat valamint az amerikai cégek aggodalmait és az alapvető személyiségi, polgári és szabadságjogokat is.

2. Növelik a rendszer átláthatóságát és megerősítik az amerikai állampolgárok személyes adatainak védelmét. Ennek első lépéseként feloldják a titkosítását és nyilvánosságra hoznak néhány eddig titkosnak minősített dokumentumot. Kiemelte a FISA 702külföldiek megfigyelésére vonatkozó fejezet – és a FISA 215 (dokumentumai jobb minőségben) – ez tette lehetővé a telefon metaadatok tömeges rögzítését – dokumentumokat. Megalakítanak egy a kormányzattól független testületet, amelynek a véleményét kikérik a fontosabb esetekben.

3. Szigorítják az előbb említett FISA 702 keretében történő megfigyelésekre vonatkozó szabályokat.

4. Az FBI a nyomozásra vonatkozó bármilyen adat megadása nélkül kérheti a cégektől bizonyos adatok kiadását. Ezek a kérések azonban adott idő után automatikus kikerülnek a titkosítás hatálya alól, hacsak a hivatal nem bizonyítja a további titkosítás szükségességét. A cégek az eddig engedélyezettnél több információt hozhatnak majd nyilvánosságra a kormányzati kérésekkel kapcsolatban.

Obama ismét kitért a korábban kiszivárgott tömeges telefon metaadat tárolásra. (Aki idáig bírta, már biztos kívülről fújja, hogy erre a FISA 215 adja a jogi felhatalmazást.) Elismételte, hogy csak metaadatokat tárolnak és nem magát a hívást.

Érdekesség, hogy itt elmondott egy konkrét esetet, amivel indokolni kívánta a metaadat gyűjtés szükségességét. Természetesen megint a 9/11-es lapot játszotta ki. A történet szerint Khalid al-Midhar az egyik 9/11-es repülőgép eltérítő San Diego-ból felhívott egy ismert jemeni al- Qaida bázist. Az NSA ugyan látta a hívást, de - feltehetően jogi okokból -, nem láthatta, hogy a hívás egy már Amerikában tartózkodó személytől ered. Ilyen fajta hiányosságok megoldására született a FISA 215, ami ezen felül akár krízishelyzetekben - például robbantásos merénylet után - is segítheti a kapcsolatok gyors feltérképezését és az esetleges tettesek kommunikációjának követését. De természetesen ezt csak szükség esetén használják fel és nem az átlag amerikaiakat követik vele.
Megj.: Ezt persze most higgyük el becsszó, mikor korábban ő mondta, hogy láttunk már olyat, hogy az ilyen jellegű adatokkal visszaéltek.

Az eddig történteket figyelembe véve azonban belátják, hogy szükséges a FISA 215 jelenlegi formájának módosítása és egy új megközelítés bevezetése. Ennek az új módszernek azonban képesnek kell lenni arra, amire a mostani rendszer, de a nélkül, hogy az adatok a kormányzathoz kerülnének. Ezt a szakértők a megbeszélések során vagy harmadik fél bevonásával képzelték elérni, vagy úgy, hogy a szolgáltatók tartanák meg a szükséges adatokat, amikben a hivatalok szükség esetén kereshetnének. A harmadik fél bevonását egyből ki is zárta - ennek fel se kellett volna komolyan merülni - a szolgáltatóknál tartott adatok pedig mint mondta a szolgáltatókra róna plusz technikai terhet és csak áthárítaná rájuk a jogi problémákat.

Voltak olyanok is, akik a jelenlegi rendszer módosításával képzelik megvalósítani az új követelményt de ez az irány még további kidolgozást igényel.
Megj. : Úgy tűnik, valójában semmi új ötletük nincs arra, hogy mit fognak tenni és leginkább minden marad a régiben csak más ruhát adnak rá.

Addig is amíg kitalálják mi legyen, azonnali változtatásokat léptetnek életbe.

1. Az első ilyen, hogy az eddigi három mélységű távolság helyett csak két mélységig követik a megfigyelt személyek kapcsolatait.
Megj.: A három szint elsőre talán nem tűnik soknak. De van elmélet amely szerint a világon bármely két ember legfeljebb 6 távolságra van egymástól.

2. A második lépés pedig tovább keresni a megoldást a FISA 215 problémára. Erre határidőként március 28-at nevezte meg Obama.



Foglaljuk össze milyen "konkrétumokat" jelentett be Obama eddig a beszédében illetve mi olvasható ki a kiadott direktivából.

1. A direktíva értelmében jobban figyelembe veszik a szövetséges országok, az amerikai cégek és az amerikai állampolgárok érdekeit.
Na de kik a szövetséges országok? Mit jelent a figyelembe vétel?

2. Feloldották pár dokumentum titkosítását és ezzel illetve majd jövőbeni lépésekkel nagyobb átláthatóságot biztosítanak. Létrehoznak egy független testületet akinek a véleményét kikérik majd a fontosabb esetekben.
De, hogy mikor kérik ki a testület véleményét és milyen "jogköre" lesz a testületnek arról nem mondott semmit.

3. Szigorítják a FISA 702 keretén belül végzett megfigyelésekre vonatkozó szabályokat.
A szigorítás módjáról azonban nem mond lényegeset.

4. Az FBI által igényelt adatok egy előre megadott idő után nyilvánossá válnak, kivéve ha a hivatal a további titkosítás szükségességet igazolni tudja.
Sem az időtávot nem nevezte meg sem a szükségesség igazolásának módját - mint például bírósági végzés - nem definiálta. A direktívában van utalás rá, hogy a külföldiekre vonatkozóan 5 évben maximalizálják azon adatok tárolási idejét, amiről egyéb rendelet - pl. az Executive Order 12333 - nem rendelkezik.

5. A kommunikációs cégek az eddiginél több információt hozhatnak majd nyilvánosságra a hozzájuk érkező kormányzati adatkérésekről.
De nem tudtuk meg mit szabad majd a cégeknek közölni.

6. Mostantól csak 2 kapcsolatnyi távolságig követik a megfigyeltek kapcsolati viszonyait az eddigi 3 helyett.
Ez végre konkrét. Ez azt jelenti, hogy az eddigi
Gyanúsított -> Gyanúsított fogorvosa -> Fogorvos barátnője -> Barátnő vízvezetékszerelője
lánc ezek után csak a Fogorvos barátnőjéig fog érni de ő még benne lesz.

7. Elindítottak egy egyeztetési folyamatot aminek keretében megpróbálják a tömeges metaadat gyűjtés rendszerét megújítani, hogy bár ugyan azt tudja mint eddig, de ne kerüljenek a kormányhoz az ehhez szükséges adatok.
Azonban úgy tűnik, ötletük sincs hogyan tegyék ezt és valószínű a végén minden marad a régiben.

Az eddigiek összefoglalásul azt mondanám, hogy a beszéd sokkal inkább védte, indokolta és magyarázta a kiszivárogtatott tevékenységeket illetve az azt végzőket, és kevésbé foglalkozott a jogsértésekkel illetve azok jövőbeni kezelésével. Szinte semmi számon kérhető konkrétumot nem tartalmazott arról, hogy milyen tényleges változtatások fognak történni. Ködös ígéretek ugyan elhangzottak, de a beszéd alapján kérdéses, hogy akarnak-e és fognak-e bármin is ellenőrizhető módon érdemben változtatni, azon kívül amin technikailag muszáj lesz.
Maradjunk annyiba, hogy az elvi lehetőség megvan rá.


Üzenet a tengeren túlra


Ezek után Obama a külföldnek üzent. Megint felhívta a figyelmet az USA egyedülálló felelősségére a hírszerzés terén, és hogy ez nem csak Amerika és az amerikai állampolgárok de a szövetséges országok és azok állampolgárainak érdekét is szolgálja.

A bizalom visszaszerzése érdekében azonban egy új direktívát adott ki az elnök, amelyben szabályozzák a külföldre irányuló hírszerzési tevékenységet. Az USA a tengeren túl csak nemzetbiztonsági esetekben fog technológiai hírszerzési (SIGINT) tevékenységet folytatni és nem fogja válogatás nélkül olvasni az átlag állampolgárok email-jeit és lehallgatni a telefonhívásait. Nem fog hírszerzési tevékenységet folytatni azért, hogy elhallgattassa az őket kritizáló vagy az övéktől eltérő véleményt hangoztató személyeket, hogy hátrányos helyzetbe hozzon bárkit az etnikuma, neme, faja, szexuális beállítottsága vagy vallása miatt vagy, hogy gazdasági előnyt biztosítson amerikai cégeknek vagy az amerikai kereskedelmi szektornak.

A tömeges adatgyűjtést az ügynökségek ezután csak a következő speciális esetekben használhatja: kémelhárítás, terrorelhárítás, kiberbiztonság, illegális fegyverkereskedelem - ez alatt akár tömegpusztító fegyvereket is értenek -, nemzetközi bűncselekmények.

Obama példa nélkül álló lépést tett, hogy kiterjesszék az amerikai állampolgárokat megillető jogok egy részét a külföldiekre is. Korlátozni fogják a külföldiekről begyűjtött személyes adatok tárolásának maximális idejét és felhasználásának módját - lásd a direktíva 6. oldalát, ami alapján, ha másként nincs szabályozva akkor 5 évig őrizhetik meg az adatokat. Kiemelte, hogy nem nyomoznak azok után az átlag állampolgárok után akik nem jelentenek veszélyt az USA biztonságára, és hogy ezen állampolgárok személyiségi jogaikat figyelembe fogják venni.

A fentiek igazak a külföldi vezetőkre is. Ha nincs kifejezett nemzetbiztonsági oka, nem fogják megfigyelni a szövetséges vagy baráti államok vezetőit.

Világosan kijelentette, hogy az amerikai titkosszolgálatok továbbra is fognak információt gyűjteni a kormányok szándékairól, ugyan úgy, ahogy azt minden titkosszolgálat jelenleg is teszi.
És nem fognak elnézést kérni azért, hogy az ő titkosszolgálatuk sokkal hatékonyabban működik.
De a baráti vagy szövetséges országok vezetői megnyugodhatnak, hogy partnerként fogják őket kezelni.

Ezek után a fentiek biztosítása érdekében szervezeti változásokat jelentett be.
* Kineveznek egy hivatalnokot, akinek feladata a technológiai hírszerzéssel kapcsolatos nemzetközi tárgyalásokban való képviselet lesz.
* Egy másik hivatalnok feladat a bejelentett személyiségi jogvédelmi folyamat átalakítása lesz oly módon, hogy az eddigieknél jobban vegye figyelembe a jogokat, de ugyan akkor segítse a külföldi partnereket a bűn és terror elleni harcban.
* Átfogóan ellenőrzik a tárolt adatokat személyiségi jogi szempontból. Az ezt végző jogi, technológiai szakértőkből és üzleti szereplőkből álló csoport áttekinti mind a publikus mind a privát szektorban összegyűlt adatok által okozta problémákat, megpróbál nemzetközi normákat felállítani ezen adatok kezelésére és az információ cseréjére oly módon, hogy az megfeleljen a személyes adatvédelmi és a biztonsági követelményeknek.

Obama elismerte, hogy néha úgy tűnhet, mintha Amerika más normák szerint működne és az, hogy egyesek szerint a kormányt a legrosszabb szándékok vezérlik frusztráló lehet.

De senki nem kéri Kínát, hogy nyíltan beszéljen a megfigyelési gyakorlatáról vagy Oroszországot, hogy kezdjen személyiségi jogi kérdésekkel foglalkozni.

Amerika pont azért működik más normák szerint mert ők azok akik nyíltan próbálják védik a személyiségi jogokat és az emberi méltóságot.
A világ Amerikától, mint a totalitárius rendszerek, a fasizmus és a kommunizmus legyőzőjétől várja, hogy kiálljon a szabadságjogokért.


Nos a beszéd végén egy klasszikus jutott eszembe.

Hofi Géza - Szabhatjuk
"Milyen hosszan mondta! És milyen keveset."

Ja nem, nem a rendszerek összehasonlítása miatt jutott eszembe Hofi.

Obama alig érintett valamit a beszédében a kiszivárogtatott tevékenységek közül, és még az említettek esetében sem világos, hogy végül is milyen számon kérhető lépések fognak történni. Számonkérhetetlen ígéreteket sokat hallottunk, de még a kiadott direktíva elolvasásával sem juthatunk közelebb az ígéretek megfejtéséhez. Arra pedig még utalás sem történt, hogy a megfigyeléseken magukon változtatnának.

Félreértés ne essék, nem gondolom és nem is vártam, hogy majd a titkosszolgálatok működésének részleteit megismerjük. Ez nyilván badarság lenne. Ahogy azt sem gondoltam, hogy most hirtelen felhagynak a SIGINT vagy egyéb hírszerzési tevékenységgel. De, hogy egyáltalán ne mutassák a megbánás jeleit, és hogy semmi konkrét a publikum számára később ellenőrizhető lépést ne jelentsenek be azt sem gondoltam volna.

Az pedig tényleg mesteri, hogy minden mondatban van elbújtatva egy kiskapu.
Kapuk elhelyezésében most már tudjuk a politikusok és az NSA is kiválóan teljesít.

Ja és még valaki &;



Hivatkozások
   * Az Obama beszéd
   * Az Obama direktíva

Elemzések - ezeket a post megírása után gyűjtöttem össze így a véleményemet nem befolyásolták. Bárminemű egyezés csak a logika műve.
    * NYT
    * NBC
    * The Guardian
    * CSMonitor reagálások
    * Truth-Out

Friday, 22 November 2013

My Anti-Microsoft Mugs

I do not like negative campaigning but when I read the story about Microsoft`s anti-Google mugs and the answer from Google I felt the need to quickly made my versions.




Tuesday, 17 September 2013

Az NSA botrány ahogy én látom

Ezt az összefoglalót először facebookon tettem közzé ,
majd később az androbiten is megjelent egy kedves kollégámnak köszönhetően. 
De gondoltam itt is megjelentetem utólagosan. 

    The world is a dangerous place to live
    not because of the people who are evil,
    but because of the people who don't do anything about it.

                                               Albert Einstein


2013.06.06.          
Hír:
   Kiderült, hogy az USA kormánya több millió Verizon ügyfél hívásának adatait gyűjtheti össze egy titkos engedély alapján.

   A magyarázat szerint, mivel csak a hívások metaadatait tárolták - ki kit hívott, mikor és mennyi ideig tartott a hívás - de magukat a hívásokat nem, és a metaadat nem minősül kommunikációnak, ezért nem volt szükség külön engedélyre minden egyes adat eltárolásához.

Megjegyzés:
   Bár már önmagában ennek az adatgyűjtésnek a kitudódása is elég kínos - legalábbis Obama arcán szerintem látszik némi kín, amikor próbálta védeni a dolgot - itt még főként csak a személyiségi jogi aktivisták hangoskodtak. Többfelé lehetett olvasni és hallani olyan véleményeket, hogy ez még simán belefér egy titkosszolgálat tevékenységébe. 
   Érdemes azt is megjegyezni, hogy ez a fajta metaadat minden telefon szolgáltató rendelkezésére áll és azt legalább statisztikai célra tipikusan fel is használják, viszont ők nem látják a másik szolgáltatók adatait. Látják viszont a más hálózatba tőlük menő és más hálózatból hozzájuk érkező hívásokat.

   A később megismert adatok alapján azonban kijelenthetjük, hogy ez csak a bemelegítés volt.

2013.06.07.          
Hír:
   Az NSA internet “lehallgatási” botrányának kitörése. Az első #Prism dokumentumok megjelenése.

   A dokumentumok szerint az NSA-nek közvetlen hozzáférése volt több internetes cég, köztük a Google, Apple, Yahoo rendszereihez. A projekt #Prism néven futott 2007 óta. A dokumentum szerint a lehallgatás a cégek tudtával történt, amit azonban pl. a Google és az Apple azonnal cáfolt.

Megjegyzés:
   Az előzőekhez képest itt fontos újdonság (és ettől szólt igazából nagyot), hogy már nem csak metaadatról van szó, hanem a teljes kommunikációról magáról. Azaz pl. az e-mail-ek tartalma vagy a meglátogatott weblapok tartalma is a megfigyelés tárgyát képezi, nem beszélve a chat-ről illetve az internet alapú hanghívásokról. Ez merőben szembe megy azzal az Obama által korábban a telefonos hírben hangoztatott védekezéssel, hogy csak metaadatokról volt szó.

   A törvényességet azzal magyarázzák, hogy a törvény lehetőséget ad a programban résztvevő cégek Amerikán kívül élő felhasználóinak, vagy azon amerikai felhasználóknak, akiknek a kommunikációjában nem Amerikában tartózkodó is részt vesz megfigyelésére.
Bár itt is találtak magyarázatot a törvényességre, azért itt már jóval több ember érezte úgy, hogy az ilyen jellegű megfigyelés tényleg törvénytelen lehet.

   A megismert adatok alapján az tűnik a legvalószínűbbnek, hogy technikailag a lehallgatást az üvegszálon haladó adatok "bontásával" hajtják végre. Ez megmagyarázná azt is miért nevezték a projektet #Prism -nek.
Mivel itt a teljes forgalmat megkapják, legalábbis azt a forgalmat ami a #Prism csomópontokon átfolyik, szakmailag nagyon érdekes lenne tudni, hogy hogyan elemeznek ekkora mennyiségű adatot, mit keresnek benne és milyen technológiákat alkalmaznak.

   Két dolgot érdemes még megemlíteni és mind a kettő a titkosítás témakörhöz kapcsolódik. Amikor kiderült a #Prism lehallgatás akkor a szakértők azt mondták, hogy azért nincs nagy vész, mert a legtöbb adat titkosított csatornán halad keresztül, amibe nem lehet belelátni. Bár bizonyos információk szerint a titkosított adatokat is mentették a lehallgatás folyamán, ám ezeket egyelőre visszafejteni nem tudják. A tárolás célja az volt, hogy ha később lehetségessé válik az adatok visszafejtése, akkor azt majd megtehessék akár célzottan valakire fókuszálva.

   Az első fontos dolog, hogy pl. a gmail böngészős változatának használatakor a böngésző titkosított csatornát használ, - gmail-nél az imap szerver is támogat titkosítást - azonban a levél címzetthez juttatása legtöbbször titkosítatlan protokollon - smtp - történik. Ez még akár akkor is lehallgathatóvá teszi az e-mail-eket, ha gmail-ről gmail-re megy az e-mail, de különböző szerverek között utazik az e-mail és közben áthalad egy #Prism csomóponton. Egyébként is a legtöbb kommunikáció esetében a két fél között nem áll fent úgynevezett end-to-end titkosítás tehát valahol lehallgatható lesz a kommunikáció.

   A másik dolog, hogy bár a titkosítás mint technológia rendelkezésre áll és pl. a gmail webes felületéhez is van viszonylag egyszerűen használható e-mail titkosítást - PGP/GPG - kínáló böngészőbe beépülő program, és ennek használatával valódi end-to-end titkosítást érhetünk el, de az ehhez szükséges kulcsok generálása és megfelelő kezelése egyáltalán nem triviális, illetve ennek használatához mindkét félnek rendelkeznie kell a megfelelő kulccsal. Továbbá az e-mail metaadatok ilyen módon sem titkosíthatóak.

2013.06.10.          
Hír:
   Edward Snowden felfedi kilétét és, hogy Hong Kongban tartózkodik.

Megjegyzés:
   Elsőre logikusnak tűnik, hogyha az NSA tudta, hogy ki szivárogtatja ki az adatokat, akkor Snowden-nek érdeke volt megmutatni magát, nehogy csendben eltegyék láb alól. Azonban ha megmutatja magát, akkor egy másik titkosszolgálat, vagy egy elvakult fanatikus is megölheti - mivel tudják ki volt - és ezzel az NSA-re terelné a gyanút. Tovább Snowden azt nyilatkozta, hogyha vele történik valami akkor is nyilvánosságra kerülnek az adatok. Tehát akár emiatt is érdeke lehetne másik titkosszolgálatnak megölni. Ennek ellenére Snowden él. Nos, azt hiszem arra, hogy miért fedte fel magát - és hogy jól tette-e - csak az idő fog választ adni.

2013.06.26.          Hír:
   Putin elismerte, hogy #Snowden egy Moszkvai reptéren tartózkodik.

   Az USA-ból többen is üzentek neki - ki finoman ki kevésbé - hogy adják ki #Snowden -t.

2013.08.01.          Hír:
   Dokumentumokkal bizonyították, hogy az NSA 100 millió Angol Fontot fizetett a Brit Kormányzati Kommunikációs Központnak, - GCHQ - hogy segítse a lehallgatást.

Megjegyzés:
  A dolog lényege, hogy a brit szervezetek is nyakig benne vannak. Szerintem ez sem kellett volna túl nagy meglepetést okozzon. Nyilvánvaló, hogy minden titkosszolgálat nagyjából ugyanazt akarja. Tudni mindenről. Az is világos, hogy a titkosszolgálatok szükség esetén össze szoktak dolgozni. Az is elég egyértelmű, hogy a titkosszolgálatok elég szabadon tudják értelmezni a törvényeket a tevékenységük igazolására. Mivel eddig nem volt bizonyíték ilyen jellegű tömeges adatgyűjtésre ami ráadásul országhatárokon átível, azért ez is nagyot durrant. Ráadásul fontos momentum volt, mert kihozta az egész botrányt az USA területéről és globális szintre emelte.

2013.08.20.          
Hír:
   A Guardian-nál megsemmisítettek olyan merevlemezeket amin a Snowden anyagokat tárolták.

Megjegyzés:
   A brit hatóságok többszöri nyomásának engedett a Guardian, amikor megsemmisítették az adathordozókat. Hozzátették azonban, hogy az anyagok megtalálhatóak máshol is az ország határain kívül, tehát tulajdonképpen csak az országban lévő adatokat semmisítették meg, nem az összes adatot. Tették mindezt egyébként azért, mert a hatóságok azzal fenyegették meg őket, hogyha nem teszik meg ezt, akkor ők fogják lefoglalni az adathordozókat, ezt pedig a Guardian el akarta kerülni. Nem ismerem a vonatkozó jogot, de amennyiben ez igaz, akkor szerintem még elég kíméletesen is jártak el velük szemben, mert ahelyett, hogy simán rájuk törik az ajtót, adtak nekik időt a cselekvésre. 
   Az már kevéssé volt kedves a hatóságtól, hogy David Miranda-t a Heathrow reptéren terrorizmus gyanújával őrizetbe vették és a maximálisan megengedett 9 óráig fogva tartották. Ilyen esetben sokkal kevesebb joga van a gyanúsított illetőnek, mint normál esetben, amivel a hatóságok állítólag próbáltak is visszaélni.

2013.09.05.          
Hír:

   Nem egyértelmű, hogy pontosan hogyan, de a dokumentumok szerint hosszú ideje többféle módon is azon dolgozott az NSA, hogy a különböző titkosításokat lehallgathatóvá tegye. A módszerek között feltételezések szerint szerepelt az algoritmusok gyengítése és nagy titkosítással foglalkozó cégek befolyásolása, melynek során különböző kiskapukat építtettek a kereskedelmi rendszerekbe. A dokumentumok szerint a 10 éve futó program 2010-ben ért el áttörést, amikorra is a legtöbb interneten használt titkosítást képesek voltak megkerülni.

Megjegyzés:
   Számomra a dolog innentől kezd igazán érdekessé és aggasztóvá is válni egyben. Arról, hogy az algoritmusok - pl. az AES - mennyire biztonságok voltak már találgatások régebben is. De amíg egy titkosítási algoritmusban - amit egyszer már elfogadtak - nem találnak hibát, addig jónak veszik. A TLS-t is bizonyos esetekben lehet törni. Ám az a kijelentés azért elég meredeknek tűnik, hogy az internetes titkosítások nagy részét fel tudják törni. Mivel semmit nem lehet tudni arról, hogy hogyan csinálják, ez nagyon veszélyes lehet. Mert ha az NSA meg tudja tenni, akkor honnan tudhatjuk, hogy más nem? És igazából ez a kérdés független attól, hogyan csinálják. Ha akár azt a végtelenül hülye ötletet vesszük, hogy a földönkívüliek adtak egy eszközt ami ezt tudja, akkor sincs rá garancia, hogy nincs másik ilyen eszköz más kezében. De a probléma akkor is fennáll, ha azt a sokkal valószínűbb eshetőséget vesszük, hogy az algoritmusok gyenge pontjait vagy szoftverbe épített hátsó kapukat használnak. Más is megteheti ezt, ha ilyenek léteznek.
   Márpedig, ha más is meg tudja tenni, akkor innentől a biztonságos kommunikációt igénylő alkalmazásokkal mi lesz? Nem fizetünk online bankkártyával többet? Nem tudunk netbankolni?    A titkosítások mellett ezeket a technikákat pl. digitális aláírások és tanúsítványok készítésére is használják. Mivel nem tudjuk milyen messzire jutott az NSA, vagy bárki más a feltörésben, lehet ezek is használhatatlanok lesznek? Akkor viszont pl. a szoftverekbe épített biztonsági ellenőrzéseket is ki lehet játszani. Pl. egy Windows frissítés nem is a Microsoft-tól jön de a rendszer úgy fogja látni, hogy hitelesen onnan jövő frissítés, miközben éppen a kedvenc kémprogramját telepítjük, jobb esetben az NSA-nek. Ne adj isten az összes digitális aláírás hamisíthatóvá válik?

   Szerintem ez messzebbre vezet, mint egyszerűen csak a magánszféra megsértése, az e-mailek és chat-ek lehallgatása. Ahogy fent olvasható, két módszert említ a dokumentum.

   Az algoritmusok gyengítése esetén a védekezés, illetve a megoldás viszonylag egyszerű lehet. Ki kell kapcsolni az érintett titkosító algoritmusokat. Algoritmusok kézi tiltására már eddig is volt példa, amikor valamelyik algoritmusról kiderül, hogy nem megfelelő, akkor azt a szerver illetve a kliens oldalon is lehet tiltani. Sok kliens, illetve szerver azonban kényszerűségből meghagyja ezeket a "rossz" algoritmusokat is mivel a kikapcsolásuk a specifikációt és a kompatibilitást sértené. Ha ez a helyzet akkor következő lépésben az érintett algoritmusok listája szivároghat ki.

   A másik módszer a kereskedelmi, vagy akár nem kereskedelmi - bár erről nem volt szó - termékekbe épített kiskapuk használata. Nos ez már egy nehezebb terület. Ebben az esetben azt feltételezném, hogy következő lépésben az érintett cégek/rendszerek listája fog elkezdeni szivárogni. Hogy mi lesz ezekkel a cégekkel az kérdés. Vissza tudják-e valaha szerezni ezek a cégek a bizalmat? Illetve bízhatunk-e ezután bármilyen titkosításban? A zárt kódúak eleve problémásak lesznek. A nyitott kódúak esetében jobb a helyzet, de azokat is végig kell nézni, illetve a jövőben folyamatosan figyelni a módosításokat. Igazából abban sem vagyok biztos, hogy a bizalom el fog veszni. Hiszen ezek a cégek/rendszerek "CSAK" megfeleltek a törvényi körülményeknek. Nem véletlenül perli most a Google és a Microsoft, hogy nyilvánosságra hozhassák azt amit ők tudnak.

   Ami itt még felmerült bennem mint kérdés, hogy mit szenved az NSA ezzel az egésszel. Csak meg kell szereznie a nagy úgynevezett ROOT CA-któl a megfelelő kulcsokat, és bármit lehallgathatnak. Erre a fajta tevékenységre azonban egyelőre semmi jel nem utal.

   Ezzel az infóval az eddigi "a titkosítás megvéd a lehallgatástól" teória is megbillent kicsit, mivel nem tudjuk melyik véd meg és meddig.

   Azért szögezzük le, hogy amíg nem derül ki több információ, nem tudhatjuk, hogy mennyire rossz a helyzet. Lehet csak felfújták a dolgot a jelentésben, hogy jobban mutasson. Úgyhogy egyelőre még ne dőljünk a kardunkba.

2013.09.08.    
Hír:
   Újabb dokumentumok kiszivárgása, amelyekből a legfelkapottabb a Brazil Petrobras olaj óriás lehallgatását bizonyító dokumentumok lettek. Ezek a dokumentumok az új ügynököknek szóló képzések anyagai voltak, amelyek azt mutatták be, hogyan lehet a kormányzati, üzleti szervezetek belső hálózatához hozzáférni és megfigyelést folytatni. Az nem derül ki a dokumentumokból, hogy milyen mélységű volt a lehallgatás és pontosan milyen adatokhoz jutottak hozzá, de a tanfolyami anyagban szereplő adatok a szakértők szerint valódinak tűnnek.

Megjegyzés:
   Két ok miatt került épp a brazil lehallgatás a középpontba abból a sok mindenből, ami az új dokumentumokból kiderült. Egyfelől a dokumentumok bizonyították, hogy az NSA az USA területén kívülre is kinyúló kémkedési tevékenységet is folytat együttműködve más országokkal. A másik ami fontosabb, hogy gazdasági/pénzügyi jellegű kémkedést is folytatnak. Ennek azért volt hírértéke, mert pár nappal korábban pont ezt tagadták egy levélben.
   A Guardian cikke szerint az NSA azt is elismerte, hogy nem csak terrorellenes tevékenységet folytat, hanem a pénzügyi válságokat előre jelzendő adatokat is gyűjtenek. Nyilvánvaló, hogy ilyen jellegű adatok akár versenyelőnyhöz is juttathatják az ezeket birtokló cégeket.
   Szerintem azonban az előző két pont sem kellene nagy meglepetést okozzon. Végül is kémkedésről beszélünk. Számomra a cikk igazi hírértéke technológiailag abban a mondatban van, ami azt mondja, hogy az NSA képes volt úgynevezett man-in-the-middle - magyarul közbeékelődéses - támadást végrehajtani anélkül, hogy azt a kommunikációban résztvevő felek észrevették volna. Gyakorlatilag ez azt jelenti, hogy mind a kliens, mind a szerver azt hiszi a csatorna közöttük titkos, és csak ők tudják írni/olvasni, de valójában mind a ketten egy közbenső entitással kommunikálnak, aki minden lát és írni is tud bele. Ez a korábban megfogalmazott félelmeimet - lsd. banki adatok biztonsága, illetve szoftver frissítések megbízhatósága - támasztja alá. Illetve az egyik dokumentum arra is utalhat, hogy az NSA valahogy érintett lehetett a DigiNotar nevű ROOT CA kulcsának ellopásában. Az, hogy a ROOT CA-k kulcsának megszerzésével tudják "dekódolni" a titkosított forgalmat, számomra sokkal hihetőbb, mint a feltört algoritmus. Azonban az sem kizárt, hogy ezeket a technikákat - ROOT CA, gyenge algoritmus és beépített backdoor - egymás mellett alkalmazzák.
  
   Valójában amíg sokkal több részletet meg nem tudunk az alkalmazott technikákról, addig a jelenleg elterjedt titkosításokban és titkosító programokban nem érdemes megbízni. Persze, hogy tehetünk-e mást az egy jó kérdés. Úgy gondolom egyelőre nem. 
  Várjuk a következő csomagot!


Gondolom hamarosan jön a folytatás!



Sunday, 3 March 2013

Hortonworks Data Platform 2.0 (Alpha)

In the last days I was testing Hortonworks Data Platform 2.0 (Alpha). Previously I mainly used Cloudera distributions but because of this bug in CDH 4.1.3 I wanted to test alternatives. And I choose HDP.


Note: This bug practically means that using RCFILE is useless with hive-0.9.0. The column pruning is not used by hive at all. Now it seems that the problem is in HIVE-0.9.0.

Unfortunately there is a bug also in HDP 2.0. This is not so serious however. When Ambari is  used for automated installation it can fail with  "Oozie test Fails" or if Oozie is not selected than with "Hive/HCatalog test Fails" message and the deployment log will show the following error message:

 "\"Sun Mar 03 21:38:03 +0100 2013 /Stage[2]/Hdp2-hive::Hive::Service_check/Exec[/tmp/hiveSmoke.sh]/returns (notice): FAILED: Hive Internal Error: org.apache.hadoop.hive.ql.metadata.HiveException(MetaException(message:Could not connect to meta store using any of the URIs provided))\"",

Searched for that message and found this thread mentioning that similar error can be caused by setting MYSQL host instead of leaving blank. 

I made many installation to tetst it and this is true. If you specify MYSQL host - even if you specify it properly - installation is always failing. But workaround is easy. Just leave MYSQL host field empty.

Note: I really like the Hortonworks approach - installation, configuration file handling and operation - compared to the Cloudera one but also missing some features like  decommissioning, role changes (datanode,tasktracker) of nodes.

Saturday, 15 October 2011

A bad weekend of Apple, Ubuntu and me

Over the weekend I have had 2 technical problems. And a third one which was the emotional consequence of the 2 technical ones.

So the first problem was a result of iOS5 update. My iTouch 4th gen became unstable. I liked my iTouch, iPad and iXXXXX because they were always responsive and reliable. No lags no glitches no errors. But after I have installed iOS5 on my iTouch. My oh my!!! Lags are there and makes me feel like on Windows.
The other issue seems to be a bug. You can test it by yourself.
Start "App Store" - Select "Updates" - Select "Purchased" - Select "Not on this iPod" - Swipe right to left on any item and then select the "Hide" button.
In my case "App Store" always does exit.
Steve Jobs have died just one week before the release of iOS5 and here we are. Everything I really like for iOS devices have gone. Think about it.

The other problem is more serious. And to be honest more depressing to me.
I have upgraded my Ubuntu 11.04 to Ubuntu 11.10 on my "office" notebook.
And for first look I hit bug "Booting system without full network configuration..."
What does it mean you may ask? A normal user who runs into this bug can not work anymore on the machine. So this is THE experience a normal user can not tolerate and will change to something else. Good question what the next choice will be. Back to windows?

To me the conclusion was that instead of companies making products more stable -  Apple and Linux like - Apple and Linux are making themselves more of a Microsoft like. And sorry to say but that is really-really depressing me.

I beg you Apple and Ubuntu to follow your own path and forget the Microsoft one.

Friday, 10 June 2011

Why ec2-ami-tools - ec2-upload-bundle - hangs

Me and my colleagues had been fighting an issue for some days. Since it made me really-really f**** upset I decided to investigate it now.

The issue: is that if you are behind a proxy (not necessarily) - http or socks does not matter much - you might have problem with ec2-ami-tools. When you start ec2-upload-bundle it does nothing just looks like hanging. We had been waiting for some minutes but nothing happened. Actually it is trying to do something but can not start upload.
In contrast on my home network ec2-upload-bundle almost immediately starts uploading and showing a message to indicate it.
So what is wrong? Why this is happening from behind a proxy? Is it proxy related?

We have tested many possible workarounds without any luck.
First we have specified http_proxy and https_proxy of course but it did not work.
Then we also tried to socksify the process. Without any luck.
At that point we decided to eliminate the proxies. We got an access to a machine in DMZ and we made a dynamic port forwarding and tried to use that as a socks proxy server. And that was really surprising because even that did not work.
Everything else - Firefox, ssh - was working fine but not ec2-ami-tools.
Here we ran out of the ideas for a while.

But  of course problem happens to be solved.

So I made a tcpdump, had a look and saw that the process is trying to access a special IP address 169.254.169.254 . This is a link-local IP address and this is used by amazon within the cloud to fetch some instance specific data. It is unclear why ec2-upload-bundle is trying to reach it. It is much more unclear how the program is written to be able to hang on it. I mean it is also visible that it makes a retry before the TCP timeout (0,3,9 sec) but than it gives up and hangs.

Workaround: to the problem can be to configure this 169.254.169.254 IP on the ssh server or http/socks proxy server. Also you can try somehow locally - with a firewall - reject these connections. But you have to prevent the connection to timeout since if the connection times out ec2-upload-bundle will hang. See the note for an alternative workaround.

Note: This is working on my home machine because normally my Ubuntu Linux has a 169.254.0.0/16 route. And this is enough to prevent the timeout. But only if you are not using proxy. If proxy is in between than your own routing is not used to reach this IP but the route of the proxy is used. So you have to add this route to the proxy/ssh server if you can.

route add -net 169.254.0.0 netmask 255.255.0.0 dev eth0 # Replace eth0 with your interface.


Comment: I have less motivation now to investigate it further but probably I will check what is wrong in the code and why ec2-upload-bundle hangs in such a case.

Update 1: I have checked the source code of ec2-ami-tools and it seems the error is in instance-data.rb. The initialize method is checking if the meta data is available or not and set @instance_data_accessible according. But there is no timeout defined here so you have to wait ... It seems even the TCP timeout is not realized by the open method. A Timeout::timeout(10) { } can solve this error.

Update 2: Later in instance-data.rb the read_meta_data(path) method should call the open() method only if @instance_data_accessible is true. But this is not the case. I do not know ruby at all but this seems to be a coding error. I have just added some print command to see what was going there but do not understand the code really. Besides the open() methods here also hanging indefinitely. So this is a complete hang here.

Saturday, 30 April 2011

How to create a custom RedHat / CentOS Amazon EC2 / Cloud image

Note: Cloud computing is currently a very dynamic segment of IT and relevant changes - regarding technologies, available features and licensing - might happen anytime.

First of all you may ask why to build your own AMI when you can find many existing  - CentOS and other free - Amazon EC2 images.

The following sentences are taken from an official amazon document.

"You launch AMIs at your own risk. Amazon cannot vouch for the integrity or security of AMIs shared by other EC2 users. Therefore, you should treat shared AMIs as you would any foreign code that you might consider deploying in your own data center and perform the appropriate due diligence.

Ideally, you should get the AMI ID from a trusted source (a web site, another EC2 user, etc). If you do not know the source of an AMI, we recommend that you search the forums for comments on the AMI before launching it. Conversely, if you have questions or observations about a shared AMI, feel free to use the AWS forums to ask or comment."

So what if you do not trust those public AMIs?  And where are the official RedHat images? (Old document is here)

Update: When I started to write this post - 2011.04 - RedHat did not have any available public AMIs in amazon. Besides that RedHat licensing was really-really restrictive and using your own image required special RedHat subscription and transferring 25 subscriptions to the cloud for at least half a year (at least as much as I understood the license).
 
Some historical documents:
RedHat Cloud Computin(Had been removed)
RedHat Cloud FAQ (Archived)


Licensing in the cloud is another general problem. Amazon released EC2 beta in 2006 and went public in Q4 2008. Although 3-5 years have gone OEM licensing is still a very big problem in most cases. OEMs are trying - or seeing the results probably not really - to adapt licensing and changing the cloud (amazon) licensing very frequently. Sometimes releasing paid AMIs and covering license fees such a way, sometimes requires special licenses and sometimes allows you to use your existing licensesSo probably if you can not find something now or license is not available currently, it will be available in a month, in week or even in a day. 

Update: RedHat has released some new payed AMIs. For some additional hourly fee you can use these instances and you will not have licensing problem. Search for the owner 309956199498 in the list of available AMIs and you can see RedHat AMIs. 

See RedHat pricing here and standard pricing here for comparison.
Other historical RedHat announcements:
RedHat 5.5 32/64
RedHat 5.6 32/64
RedHat 6.0 32/64
RedHat 6.1 32/64
Common RedHat AMI updates
RedHat on Amazon EC2

So if you still want to build your own image - because of security, licensing or because you have no time to wait till it is officially released by the OEM - amazon has a GOOD description how to build your own image.

BUILDING YOUR OWN IMAGE IS ALWAYS A RISK FROM LICENSING POINT OF VIEW!!!
MAKE SURE YOU HAVE THE PROPER LICENSES BEFORE USING YOUR OWN IMAGE!!!
OR BETTER USE FREE SOFTWARES IN THE CLOUD.
(Debian, Ubuntu, CentOS)

I can only add some probably hopefully useful information.

If you want to create CentOS image via yum you have to use a pre installed CentOS operating system as a build server. (CentOS is free to use in the cloud and have a central repo even for install and update.)

If you want to create RedHat image via yum you have to use a pre installed RedHat operating system as a build server. (Licensing of RedHat might be a problem. And upgrading from the cloud via RedHat Network [RHN] is probably not the best idea.)

I recommend to use a 64bit OS version as a build platform since you can use that to build both 32 and 64 bit images. On a 32bit OS however you can build only 32bit images.

I also recommend to use the latest version of the OS. It is possible to install older version of the OS on the latest version. (It is most probably possible to install latest version of the OS on an older version but might have some unavailable new features - for example missing file system support.)

I prefer to use original kernels from RedHat and CentOS and not using the available amazon AKIs.

You can make your life easier by disabling SELinux - or at least running in permissive mode. After you could build a running image you can try to enable SELinux again if you need. (And I would suggest to use it if possible.)

When you are installing the base OS with yum the amazon document shows how to create a yum configuration file by hand. CentOS has a so called "release" file which contains the yum config. Using that it is more automatic and version safe. RedHat also has a release file but yum config is needed there.