Creare una penna USB che faccia BOOT

Scaricare la ISO voluta.

Aprire il terminale

hdiutil convert -format UDRW -o ~/path/to/target.img ~/path/to/ubuntu.iso

OSX Aggiunge il “.dmg” al file. Cancellarlo.

Lanciare

diskutil list

Inserire la penna USB

Lanciare

diskutil list

Capire quale è la penna inserita (e.g. /dev/disk2).

Lanciare

diskutil unmountDisk /dev/diskN

Lanciare

dd if=/path/to/downloaded.img of=/dev/rdiskN bs=1m

Usare /dev/rdisk al posto di /dev/disk è più veloce

Nel caso di errore dd: Invalid number ‘1m’, stai usando GNU dd. Usare lo stesso comando ma rimpiazzare bs=1m con bs=1M

Nel caso di errore dd: /dev/diskN: Resource busy, controllare che la penna USB non sia in uso. Lanciare ‘Disk Utility.app’ e smontare (NO eject) la penna

Lanciare

diskutil eject /dev/diskN

E rimuovere la penna una volta che il comando è terminato.

Fatto.

Speed Test da riga di comando con speedtest-cli!

Pochi semplici comandi:

apt-get install python-pip

pip install speedtest-cli

speedtest-cli –list | grep “Turin” (troviamo i nodi di Torino)

speedtest-cli –simple

speedtest-cli –simple –server 2316 (per usare uno dei server presi dalla lista)

Fonte: Link

GitLab – CI with git-ftp

Per prima cosa è necessario far funzionare la CI in GitLab.
Per ottenere questo obiettivo è necessario creare un runner.
Per creare un runner bisogna installare il seguente pacchetto:

apt-get install gitlab-ci-multi-runner

Dopodichè basta lanciare questo comando e inserire le info richieste:

gitlab-ci-multi-runner register

Le info richieste si trovano nella scheda “Runners” del progetto interessato.

Aggiungere nella root del nostro progetto il file .gitlab-ci.yml

Il contenuto del file sarà il seguente:

deploy:
  - deploy

deploy:
  script:
  - git-ftp init -vv -u USERNAME -p PASSWORD ftp.qualcosa.it/percorso

Dopo il primo commit bisognerà modificare il file ottenendo il risultato seguente.

deploy:
- deploy
deploy:
script:
- git ftp push -vv -u USERNAME -p PASSWORD ftp.qualcosa.it/percorso

Ovviamente questo file usa git-ftp. Se serve installarlo.

 

Link utili:
https://github.com/banago/PHPloy
https://github.com/git-ftp/git-ftp
http://www.simonewebdesign.it/git-ftp-push-ftw/
http://www.zyxware.com/articles/4192/how-to-deploy-files-from-a-git-repository-via-ftp

Multi-Tenant

Multi-Tenant. La stessa istanza di un software può essere utilizzata da più organizzazioni mantenendo i dati isolati. Un concetto semplice. Un concetto che và a nozze con il SaaS (Software as a service).

Wikipedia ci dice cosa vuol dire SaaS.

Wikipedia ci dice anche cosa vuol dire Multi-Tenant.

Multi-tenant si riferisce ad una architettura software in cui una singola istanza del suddetto software gira su un server ed è utilizzata da più di una client organization (tenant). La multi-tenancy rappresenta il concetto opposto all’architettura multi-istanza, nella quale separate istanze del software sono dedicate alle client organization.
In un’architettura multi tenant, un’applicazione software è progettata per partizionare virtualmente i suoi dati e la sua configurazione in modo che ogni client lavori con un’istanza virtuale personalizzata.

Wikipedia non ci aiuta però a realizzare praticamente qualcosa. Per questo ci sono altre fonti di informazione.

Questa immagine (fonte: quì) ci spiega la differenza tra multitenant e singletenant in modo molto semplice!

singletenant-multitenant multi-tenant

Quì è possibile trovare un interessante ed esaustivo articolo in merito a questa tematica.

Quì ci sono delle slide interessanti sul multitenant ed il PHP.

GitLab – Conosciamolo

Prima di conoscere GitLab è meglio conoscere Git.
Consiglio quindi di leggere quà: link

Se non basta c’è anche questa guida veloce per conoscere Git!

Installare GitLab su una debian è semplice. Basta seguire quei quattro passi che propone l’howto ufficiale ed in 10 minuti il tutto è funzionante.
Io l’ho fatto su di una macchina in cui ho Apache2 che gira ed ho quindi dovuto creare un virtualhost per farlo funzionare sotto Apache2.

Attenzione! Ho volutamente provato ad ignorare i requisiti minimi per l’installazione, lasciando alla VM solo 512mb di RAM, ma l’installazione si bloccava restituendo gli errori più disparati.
A questo punto sono andato sul sito ufficiale ed ho controllato i requisiti minimi dichiarati ed ho quindi dato alla VM 2GB e l’installazione di ha messo 13 secondi per terminare con successo. Tenetelo presente.

Virtual host per Apache2:

<VirtualHost *:80>
ServerName gitlab.example.com
ServerSignature Off
ProxyPreserveHost On
<Location />
Order deny,allow
Allow from all
ProxyPassReverse http://127.0.0.1:8080
ProxyPassReverse http://gitlab.example.com/
</Location>
RewriteEngine on
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteRule .* http://127.0.0.1:8080%{REQUEST_URI} [P,QSA]
# needed for downloading attachments
DocumentRoot /home/git/gitlab/public
#Set up apache error documents, if back end goes down (i.e. 503 error) then a maintenance/deploy page is thrown up.
ErrorDocument 404 /404.html
ErrorDocument 422 /422.html
ErrorDocument 500 /500.html
ErrorDocument 503 /deploy.html
</VirtualHost>

Poi lanciare i seguenti comandi (necessari per abilitare i moduli su apache):

a2ensite gitlab
a2enmod proxy_http
a2enmod proxy
a2enmod rewrite
service apache2 restart

Disabilitare Nginx a favore di Apache2:

nginx['enable'] = false

Riconfigurare e restartare GitLab:

gitlab-ctl reconfigure
gitlab-ctl restart

 

Quì un bellissimo link che spiega come utilizzare Git con NetBeans: Link
Esistono poi una infinità di client per tutte le piattaforme. Evito di linkare tutto quì che tanto basta cercare su Google!

Una utile immagine per capire come funziona (grazie Maruko):

MgaV9

E quì l’illuminante articolo dell’autore!

Link fonte del virtual host su apache2

Certificati SSL Gratuiti con startssl.com

Questo post ha uno scopo puramente informativo! Serve a segnalare che si possono avere certificati SSL Gratuiti con startssl.com!

Ho scoperto questo sito effettuando delle ricerche per ottenere dei certificati a basso costo.. questo sito permette di averne di gratuiti in poco temo! Questo è ottimo per testare le proprie applicazioni/siti che necessitano di certificati.

Link al sito: https://www.startssl.com/

StartCom offers the free (for personal use) Class 1 X.509 SSL certificate “StartSSL Free”, which works for webservers (SSL/TLS) as well as for E-mail encryption(S/MIME). It also offers Class 2 and 3 certificates as well as Extended Validation Certificates, where a comprehensive validation (with costs) is mandatory.

While certificates are free for certain uses, there are limitations imposed unless an upgrade is purchased:

  • One-year certificate validity (new certificate can be issued for free at any time).
  • One domain plus one host name per certificate (e.g. www.example.com and example.com, or www.service.example.com and example.com).
  • No commercial use[3]
  • Certificate revocation requires a fee

DDNS Server with Bind9 (and Webmin) – PT1

La problematica è molto semplice.
A casa ho un ip dinamico. Voglio raggiungere casa con un indirizzo, ma voglio realizzare da me tutta l’infrastruttura necessaria.
Ho a disposizione una macchina virtuale con un ip pubblico statico (che sarà la mia macchina dns) e una macchina linux a casa sempre accesa (che poi sarà un Mikrotik).

Per prima cosa mi sono documentato su cosa sia necessario per ottenere il mio obiettivo.
Google mi ha aiutato a colmare alcune lacune che avevo in merito alla teoria dei DNS. Le letture sono state davvero tante, non posso riportare i link per un motivo molto semplice. Non li ho segnati da nessuna parte.
Non è necessario, la teoria su dns, bind, nsupdate, nslookup ecc.. si trova sempre ovunque.

Per comodità ho installato sulla macchina virtuale debian e webmin.
In una manciata di minuti la macchina era pronta ed ho potuto fare accesso a webmin per configurare il dns tramite l’interfaccia grafica.
Voci di corridoio: Perchè webmin? Potevi fare tutto da riga di comando.
Io: Perchè a volte l’interfaccia grafica ci và. A volte il cliente la vuole. E mi è sembrato un buon momento per provarla.

Veniamo al dunque.. Ecco i passaggi.

  1. In webmin mi sono configurato la zona dns che mi interessava (noip.nomedominio.it) in modo da avere poi dei record del tipo casa.noip.nomedominio.it, casa2.noip.nomedominio.it, casa3.noip.nomedominio.it ecc.. (in realtà mi fermo a casa.noip.nomedominio.it.. è già tanto averne una! 😀 ).
  2. Sono entrato in SSH sulla macchina dns (/etc/bind/) ed ho dato il seguente comando (TSIG key):
     dnssec-keygen -a hmac-md5 -b 128 -n HOST noip.nomedominio.it.

    Nota importante. Ho provato anche con una chiave a 512, ma non funzionava.
    Sarebbe opportuno capire perchè, ma non è una cosa che al momento mi interessa più di tanto.

  3. Il comando successivo è stato il seguente:
     less Knoip.nomedominio.it.+157+31299.key

    che restituisce una riga del tipo:

    noip.herotech.it. IN KEY 512 3 157 ns7T/bv+smJ6Gd9Y2EwdhQ==
  4. In webmin sotto “BIND DNS Server” -> “Global Server Options” ho cliccato su “DNS Keys” ed ho creato una chiave che ha come ID “noip.nomedominio.it.”, algorithm “hmac-md5” e secret “ns7T/bv+smJ6Gd9Y2EwdhQ==”.
  5. Sono poi entrato, sempre in webmin, nella zona noip.nomedominio.it ed ho cliccato su “Edit Zone Options”.
    Quì, in “allow updates from”, ho inserito “key noip.nomedominio.it.”
    Fatto questo ho cliccato “Apply zone” ed “Apply configuration”.
  6. Per testare il tutto ho dato il seguente comando:
     nsupdate -k /etc/bind/Knoip.nomedominio.it.+157+31299.private -v /tmp/nsupdate.txt

    dove il contenuto del file nsupdate.txt è il seguente:server localhost

     debug yes
    zone noip.herotech.it.
    update add casa.noip.nomedominio.it. 300 A 8.8.4.4
    show
    send
  7. Fatto questo ho notato che da webmin non vedevo questo record.
    Dopo una breve lettura ho scoperto che:

    Zones that are under dynamic control via nsupdate or a DHCP server should not be edited by hand. Manual edits could conflict with dynamic updates and cause data to be lost.

    E quindi l’unico modo di vedere i record gestiti tramite nsupdate è di effettuare un transfer della zona dando il seguente comando sul terminale.

    dig @dns.nomedominio.it noip.nomedominio.it -t AXFR

Arrivato a questo punto, direi che ho le basi per far evolvere il servizio.
Manca un client che effettua le richieste di modifica della zona DNS ed una serie di script che permettono la gestione del tutto.
Ma questo lo vedrò in un secondo momento!

 

Pagine web che mi hanno aiutato o che mi aiuteranno (forse) in questa impresa:

http://jpmens.net/2010/09/28/performing-dynamic-dns-updates-on-your-dns/

http://linux.die.net/man/8/nsupdate

http://www.kirya.net/articles/running-a-secure-ddns-service-with-bind/

http://andrwe.org/linux/own-ddns

Migrate a XenServer VM without a Pool or Shared Storage

Molto bene. Ho deciso di passare ad un server più potente e performante.
La cosa più logica è prendere il nuovo server, installare Xen e migrare le macchine da un server all’altro.

Sfortunatamente non è possibile inserire nello stesso pool due server con caratteristiche tecniche differenti.
Questo vuol dire che le macchine non possono essere trasferite dal vecchio server al nuovo tramite l’interfaccia XenCenter.

E’ però possibile effettuare il trasferimento tra i due grazie a questo script!

Basta scaricarlo, estrarlo e lanciare ./migratevm

Lo script vi chiederà macchina sorgente e macchina di destinazione. L’unica premura è quella di procurarsi l’UUID della macchina che si vuole spostare digitando “xe vm-list” nella console dello Xen sorgente.

 

Link per il download (l’ho uplodato anche quì per evitare di perderlo):
migratevm-1.0.1.tar

Articolo originale (Randy grazie!):
http://djlab.com/2013/01/migrate-a-xenserver-vm-without-a-pool-or-shared-storage/

Blog di Fabio (colui che mi ha fatto scoprire lo script e che mi ha evitato ore ed ore di riconfigurazione):
http://www.nixtips.net/

Restore packages on debian server

Ovvero come installare gli stessi pacchetti che sono installati su un’altra macchina.

La descrizione semplice è:

  1. Prendere l’elenco dei pacchetti della macchina A
  2. Installare gli stessi pacchetti sulla macchina B.

Ecco quì i comandi da dare nel terminale della macchina A:

Copiare il file /etc/apt/source.list dalla macchina A alla macchina B

  • dpkg –get-selections > /tmp/installed.pkg

Ecco quì i comandi da dare nel terminale della macchina B:

  • aptitude update
  • apt-get install dselect
  • dselect update
  • dpkg –set-selections < /tmp/installed.pkg
  • apt-get -y update
  • apt-get dselect-upgrade

Attenzione! In questo modo avrete gli stessi pacchetti installati, ma non le stesse configurazioni.
Le configurazioni andranno copiate a mano!

 

Questi sono alcuni siti (da cui ho preso spunto) che spiegano in modo più approfondito i comandi sopra elencati. Nessuno di questi era però completo.. alcuni non menzionavano il file source.list ed altri non si preoccupavano del dselect update!

https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1232661
http://smanettonex.blogspot.it/2010/09/duplicare-un-server-debian.html
http://kvz.io/blog/2007/08/03/restore-packages-using-dselectupgrade/

 

Create Debian Virtual Machine with XenServer in SoYouStart (Fail Over IP)

 

Nel pannello di controllo di SoYouStart, in gestione IP, ordinare un nuovo IP ed attenderne la consegna.

Nella gestione IP si trovano tutti gli IP attualmente acquistati, come nell’immagine sotto.

uno

Sul nuovo IP che abbiamo ordinato andiamo a cliccare sull’ingranaggio e poi su “Aggiungi un MAC virtuale”.

due

Dopodichè compiliamo il form che si presenta secondo l’immagine sottostante.

tre

 

Ritornando alla schermata di gestione IP vedremo, accanto al nuovo IP, il MAC address da utilizzare per la nostra nuova VM. Copiamolo.

Ora possiamo andare sullo XenCenter e creare una nuova VM scegliendo “Install from URL” ed usare il seguente mirror.

OVH mirror:
http://mirror.ovh.net/debian/

Altri mirror: https://www.debian.org/mirror/list

Al punto “Networking” dobbiamo andare ad inserire il MAC address ricevuto nell’interfaccia di rete, come nell’immagine sotto.

4

Andando avanti partirà l’installazione classica di Debian. Arrivati alla configurazione della scheda di rete dobbiamo scegliere la configurazione manuale ed inserire i parametri riportati sotto. Dove A.A.A.A è l’indirizzo IP di failover.

La parte importante è quella relativa al gateway, dove dobbiamo inserire i primi tre ottetti dell’indirizzo IP di failover e 254 nell’ultimo.


IP: A.A.A.A -> IP FailOver
Netmask: 255.255.255.0
Gateway: A.A.A.254 -> IP FailOver Gateway (gli ultimi 3 num sono 254)
Name Server: 213.186.33.99 -> OVH

Fatto questo portiamo a termine l’installazione e la nostra debian sarà pronta e raggiungibile all’IP pubblico assegnato.

 

Ricordate di mettere qualche regola di firewall!!!!

A questo link trovate la versione per OVH.