Alicloud & RedHat Linux 7.4 BYOS

alibaba-cloud-logo

Alibaba Cloud (Alicloud or Aliyun) is a promising Chinese cloud provider that is becoming popular in the Asia-Pacific region. If you want to release services in China and be able to comply with Chinese privacy law, all your data need to stay in China. For this reason, Alicloud can be handy to start your journey in the Asian country.

Most businesses want to have the same certified workloads in China as well, and those are mostly based on RedHat Enterprise Linux (RHEL). Alicloud is a RedHat Certified Cloud Provider and offers RHEL images in their marketplace, but these images include a RedHat subscription. What if you have an Enterprise agreement and you want to use a Bring Your Own Subscription (BYOS) method?

Here are some handy tricks to bring RHEL 7.4 BYOS into Alicloud and start serving your customers in China.

Alicloud supports importing images in RAW and VHD format, which help us a lot. If you have an active RedHat subscription, you should download the RHEL 7.4 KVM guest image (see image below). This image is compatible with the Alicloud virtualization system; Alicloud is also compatible with cloud-init to customize the virtual machine at boot time. The direct link to the download page is here: https://access.redhat.com/downloads/content/69/ver=/rhel—7/7.4/x86_64/product-software

rhel guest.PNG

The next step would be converting the QCOW2 image into a RAW format. However, the conversion will expand the 500MB QCOW2 image into a 10GB RAW format. Uploading such a big file would be problematic if you do not sit in China and you have to traverse the Great Firewall of China.

As such, we will upload the QCOW2 image into Alicloud  Object Storage Service (OSS) and convert it using a temporary virtual machine in China. Create a bucket through the console and upload the image. Shall you need a GUI to perform the upload, an official GUI client named “OSS Browser” is available here: https://github.com/aliyun/oss-browser/blob/master/all-releases.md

I strongly recommend downloading also ossutil64, a CLI based tool for OSS, to be able to upload your image from the temporary Linux instance. The tool is available here: https://www.alibabacloud.com/help/doc-detail/50452.htm

Create a small Linux instance with the distro of your choice (I recommend CentOS) in your Chinese region (in my case Beijing), but ensure you have sufficient disk space. Once the instance is reachable, login and download the QCOW2 from the bucket using curl and the object URL. Convert it using qemu-img tool:

qcow-img -f qcow2 -O raw rhel-server-7.4-x86_64-kvm.qcow2 rhel-server-7.4-x86_64-kvm.img

Once converted, use the ossutil64 to upload the image to your previously created bucket.

Object Storage Service 1.PNG

If you click on the file, you can get its public URL in the preview. Copy the file URL as we will feed it into the image importer,

Object Storage Service detail.PNG

Go back to the Elastic Compute Service (ECS), select Image on the menu on the left and start the import through the “Import Image” functionality. In the OSS Object Address, insert the URL as copied before. Use Linux as operating system and RedHat as system platform. Mind to specify RAW as image format.

import image1.PNG

import image 2.PNG

The Alicloud image service will (slowly) import the image. If everything is successful, you should see an image similar to the one below:

image2.PNG

You can start a virtual machine with your newly created image and register your RedHat subscription with subscription-manager 🙂

Backing up GitLab on OpenStack

When I walk in a new customer, is not just about OpenStack, but also help them automating their internal processes, usually with Ansible. As soon as I have OpenStack up&running, the first thing I do is deploy an internal Gitlab.

I use git to keep track of the changes and the stable releases of the Ansible scripts I use to customize OpenStack images after provisioning.

Backing up Gitlab is very critical, as it holds many hours of my job. As I’m an OpenStack maniac, I find very handy to use Swift as a backup area. It is technically possibile to backup Gitlab on Swift, but in my opinion poorly documented. Here’s a quick howto I decided to share.

In Gitlab configuration file /etc/gitlab/gitlab.rb add OpenStack as follows:

gitlab_rails['backup_keep_time'] = 604800

gitlab_rails['backup_upload_connection'] = {
'provider' => 'OpenStack',
'openstack_auth_url' => 'http://keystone.openstack:5000/v2.0/tokens',
'openstack_username' => 'admin',
'openstack_api_key' => 'admin',
'openstack_tenant' => 'admin'
}
gitlab_rails['backup_upload_remote_directory'] = 'gitlab'

Note that the keystone endpoint (auth uri) MUST include the version 2.0 and MUST end with “tokens”, otherwise the fog component will fail (the ruby library used by Gitlab). As openstack_api_key specify your keystone password. If your OpenStack installation has  multiple regions, you need to add the following to the previous:

'openstack_region' => 'region-two'

Now that the file editing is done, you have to refresh the Gitlab configuration with:

sudo gitlab-ctl reconfigure

You can test if the backup is working by using the Gitlab backup command with the following command:

gitlab-rake gitlab:backup:create

In my setups, ansible files aren’t changed that much once done. I usually create a script in /etc/cron.weekly/ to backup the files every week.

Et voila’, bon appetit 🙂

Mentioned on Forrester report on OpenStack

On May 18 2015 Forrester Research Inc, the well-known independent technology and market research company, has published a paper “OpenStack is ready, are you?“.

I’m happy that I’ve been mentioned as a source for their OpenStack security research. It’s a small step, but it’s the top recognition of OpenStack knowledge, along the HP Most Valuable Professional award on OpenStack.

You can download the paper from the link below:

https://www.openstack.org/assets/pdf-downloads/OpenStack-Is-Ready-Are-You.pdf

HP Most Valuable Professional Award

MVP-logoI am very honored to receive today the HP Helion Most Valuable Professional Award for:

your considerable community contributions to OpenStack and your strong presence in the community. This exclusive award is presented to a select group of individuals, like yourself, who show strong technical skills combined with community leadership.

Suzanna K. Litwin, HP Helion Community Manager

Thanks to Suzanna Litwin and Enrico Gaetani from HP

L’Open Source dopo Heartbleed – Riflessioni “a cuore aperto”

Note for English audience: this post is Italian only, I do apologise with my English readers. Just for your information, is all about the decline of Open Source in current era and how Heartbleed reflect it.

Mi riallaccio alla discussione seguita alla scoperta di Heartbleed, il bug di OpenSSL che sta dimostrando come l’era Open Source (come ce lo eravamo immaginato) sta finendo, per fare qualche riflessione sul suo passato, presente e futuro.

Una precisazione tecnica sul post citato. Non è del tutto vero che solo i cookies possono essere intercettati e che le password sono di solito messe in forma di hash su database. In realtà é più complicato, tramite il bug Heartbleed é possibile catturare le variabili POST mandate dai browser, quindi intercettare le password mandate dai clienti. Con sistemi di accesso tramite OTP come SecurePass questo rischio non ci sarebbe stato, ma non è il momento di soffermarsi sulle soluzioni, piuttosto di guardarsi intorno.
heartbleed
L’Open Source sta arrivando alla fine di un’epoca “d’oro”, ma non ho mai avuto modo di manifestarlo pubblicamente perché mi ritengo pur sempre un “Veteran Unix Admin”.

Quali sono i motivi? Penso fondamentalmente due, alla fine.

La community volontaria è diventata grande, nel senso che ha iniziato a lavorare.

Tutti i programmatori volontari come me, che sin da “piccoli” hanno contribuito ai progetti Open Source ormai sono cresciuti, anche professionalmente, e oggi scrivono codice per lavoro. Quasi tutti noi che abbiamo fatto parte della community abbiamo perseguito il sogno Open Source e ci siamo poi scontrati con la realtà quotidiana e quella dei vendor. Solo Red Hat é stato capace di monetizzare il potenziale dell’Open Source, gli altri si dividono tra chi non ce l’ha fatta, chi vive nell’ombra (ad esempio Enterprise DB o la stessa SuSE), chi é stato acquisito da grosse realtà (ad esempio MySQL). Io ho deciso di perseguire una strada un po’ complicata, ma il “normale” sistemista e programmatore di derivazione Open ormai tende a lavorare per una multinazionale più o meno conosciuta, così come succedeva nell’epoca pre-Open Source. Si, perché vi ricordo che l’Open Source esisteva già prima di Linux e che spesso i compilatori e le librerie erano usati anche in prodotti proprietari.

Perché Linux per le multinazionali vuol dire risparmio.

Il grande successo di Linux ha fatto capire alle multinazionali che poter investire una/due risorse su un progetto Open significa risparmiare parecchio. E se un progetto é ben consolidato e funziona, neanche quella. Quindi capirete che nell’ “universo” IBM o HP (per fare nomi a caso), una persona al mondo che contribuisce a delle librerie é praticamente niente.
Perché solo una o addirittura niente? Spesso il vendor mette una persona su una libreria o un progetto Open che necessita alcune patch necessarie alla realtà aziendale, ma che la comunità’ spontaneamente non scrive. Mi viene in mente ad esempio alcune patch al codice di Apache che possano essere di aiuto a WebSphere. Se però il vendor non ritiene necessario alcuna modifica che porti benefici al proprio business, magari non dedica nessuna risorsa, ecco dove il “bug” di OpenSSL può’ non essere mai stato notato.

Progetti lightweight

Prima di esplorare il secondo motivo, una precisazione su lightweight che IMHO non significa affatto “non sono capace di lavorare in un team grande”, lightweight significa solo progetto lightweight. Posso riportare la mia esperienza di 20 anni in progetti Open Source vari, spesso questi team sono guidati da “primedonne” che non vogliono essere scavalcate. Ci sono in quasi tutti i progetti Open e spesso le discussioni sono così improduttive che per arrivare alla fine bisogna andarsene. L’altro aspetto é che nei progetti di grande respiro, e mi viene da citare ancora Apache, spesso i grossi vendor hanno degli interessi e il “comitato” influenza la direzione del progetto in qualcosa che il singolo sviluppatore non voleva o di cui non sentiva la necessità. Per queste ragioni spesso vengono avviati i progetti lightweight che finiscono “per essere un prodotto mutilato, incompleto e bacato con una release ogni 3 anni”, come diceva già l’autore del post.
Volete un esempio concreto? La mossa di Mark Shuttleworth verso Unity ha avuto delle conseguenze sulla comunità del desktop Linux, che allora stava crescendo notevolmente.
Mark aveva in mente un desktop diverso da Gnome 2 e voleva convincere Gnome a prendere un’altra strada. Alla fine Mark ha “imposto” le proprie idee creando Unity solo per Ubuntu e Gnome ha creato il suo contraltare, Gnome 3.
Risultato? La comunità si è divisa tra un ambiente che funzionicchia e uno poco usabile, fermando l’ascesa che Linux stava avendo sul desktop. Se ne sono avvantaggiate Apple, che ha avuto il suo momento di gloria, e anche Microsoft con Windows, che nonostante gli insuccessi non ha mai perso il suo predominio.

Torniamo alle ragioni del declino, l’OpenSouce fa parte dei costi dell’IT

Vi racconto un aneddoto che porto sempre ad esempio. Nel “lontano” 1997, quando lavoravo in IBM nel supporto e servizi professionali networking di AS/400 (ora iSeries), sono andato a trovare un cliente che faceva sanitari. Ho parlato con il proprietario e mi sono sentito rispondere davanti ad una proposta: “guarda, a me piace molto la tecnologia e mi piace smanettare con i computer. Ma qui facciamo cessi, quindi la tecnologia mi deve supportare a creare cessi migliori o a vendere meglio i nostri cessi. Ovviamente deve costarmi il meno possibile, perché alla fine l’IT é un costo necessario, esattamente come la carta igienica.”
Mi ricorderò sempre di questo esempio così schietto perché mi ha aperto un modo diverso di pensare.

Gli utenti comprano la tecnologia per usarla, non per studiarla.

Per fare un paragone differente, quanti di voi usano il cellulare e sanno esattamente come funziona l’architettura GSM, UMTS e LTE nei minimi dettagli? Gia’ le persone tecnologicamente avanzate non lo sapranno, pensate che all’utente consumer tipo si soffermi sull’infrastruttura GSM? L’importante che è che permetta di comunicare, di fare pettegolezzi, di farsi notare.
Sono d’accordo con la mia amica Yvette Agostini, quando dice che siamo nell’era dell’apparire e non dell’essere. Questa affermazione é vera da sempre ma oggi abbiamo i social networks e le trasmissioni che aiutano ad apparire ancora di più. Uno chef Cracco diventa più famoso grazie a Masterchef di quanto sia “Peppe Zullo” (che conosco), padrone di un ristorante pugliese ad Orsara di Puglia che dà la paga a a Cracco, a mio modesto avviso.

Cosa c’entrano il produttore di water, la società dell’apparire e Peppe Zullo con l’IT e l’Open Source? C’entrano eccome!

Facebook “appare” come una pagina web, Whatsup “appare” come un’applicazione per comunicare. Nessuna delle due mostra l’infrastruttura che c’é dietro e lo sforzo di business per crearla. Come il produttore di sanitari, gli utenti danno valore a quello che vedono e che usano, non a quello che le tiene in piedi. Ecco perché Facebook ha comprato Whatapp per 19 miliardi di dollari, mentre General Electric con 300 mila impiegati ha un valore di 826 milioni di dollari.
Tornando OpenSSL, la gente valuta l’applicazione e cosa può’ farci, relegando all’infrastruttura un ruolo di nicchia ed un puro costo. I programmatori PHP e Java, magari quelli che scrivono codice orrendo ma di effetto “grafico”, diventano dei supereroi e “noi” system administrator o contributori all’infrastruttura, che dobbiamo fare andare a calci le loro applicazioni, come “un male necessario”. Spesso, siccome ascoltano più i programmatori e i “fantomatici” consulenti a cui non farei pulire neanche casa, pure bistrattati perché ci addossano le loro colpe dell’applicativo che non funziona… ma é facile puntare il dito verso qualcun altro, spesso se queste società’ di consulenza sono brave a “condirle” al cliente finale.
Nessuno, neanche i grossi, mettono soldi e risorse sui progetti Open perché sono un costo e “non si vedono” rispetto alle soluzioni che si vedono e che possono vendere al cliente, magari sottopagando il programmatore che si occupa di infrastruttura, e lodando tutti quelli che sono customer-facing oppure che scrivono dei blog facendo copia e incolla.

Se dovessimo chiederci se l’Open Source sopravviverà e rimarrà’ “tra noi”

La risposta é forse si, ma non avrà’ tutta quell’importanza che c’é stata negli anni passati.
Sul Desktop, Apple e la politica “aggressive” di marketing funds e di price drop di Microsoft sul retail fa si’ che Microsoft sarà sempre più venduta sul desktop di Linux…. tanto alla fine, diciamocelo, il cliente userà prevalentemente un browser e poco più, mentre i tablet saranno più’ “smart” anche con una tastiera e video esterni (più’ che sufficiente per usi “normali”). Linux verra’ confinato ad un mondo desktop per settore IT o per una nicchia.
Sulla parte “Enterprise”, RedHat (e SuSe/Canonical/…) rimarranno dei vendor, esattamente come lo sono Oracle, SAP e Microsoft. Le tecnologie basilari Open rimarranno, questo perché le aziende sanno benissimo che così si risparmia, dividendosi costi e rischi, invece di investire un team intero per scrivere codice. Non mi ci vedo che Cisco, HP e IBM si riscrivano le librerie da zero. Pero’ non avranno neanche il boom di prima, ci sarà il “dialetto” OpenStack di RedHat e il “dialetto” OpenStack di Cisco, non l’OpenStack come progetto principale.
Sempre di più ci saranno i Software-as-a-Service (SaaS), l’unica vera fonte di reddito che evita di “copiare” e che imporrà dei “prezzi standard”, un po’ come gli abbonamenti telefonici che si equiparano ormai. Grazie alla diffusione della connessione Internet, così come quella telefonica, il SaaS, insieme ai vendor grossi, sono in futuro l’unico modo per continuare a fare infrastruttura.
Conscio della direzione, già da qualche anno ho deciso di intraprendere una strada diversa, seppur ancora convito dello spirito collaborativo dell’Open Source. Ecco perché nel 2011 é nato SecurePass, proprio per mettere insieme tutte le mie conoscenze e creare un vendor. Forse una strada difficile e impervia, lottando contro colossi come RSA e Computer Associates (CA), ma una strada che percorsa nel modo opportuno, mi porterà a continuare con lo spirito Open Source. Gli adaptor SecurePass, infatti, saranno rilasciati in modalità Open Source su Github.
Mi auguro che in questo mondo di apparenza, seppur largamente ridotto, lo spirito Open Source rimanga vivo tra tutti i veri appassionati di informatica.