This commit is contained in:
lucaconte 2019-03-21 15:52:18 +01:00
commit a3be5c9f8b
16 changed files with 587 additions and 0 deletions

49
arch.md Normal file
View file

@ -0,0 +1,49 @@
Prolema caratteri terminale
pacman -S ttf-dejavu kbd
visudo
group add sudo
adduser to group sudo
da AUR:
git clone https://aur.archlinux.org/blabla.git
//builda il pacchetto risolvendo le dipendenze
makpkg -p
//builda il pacchetto risolvendo le dipendenze e lo installa
makpkg -pi
//se si builda il pacchetto poi questo va installato separatamente a partire dallo "xz" generato
sudo pacman -T balbla.tar.xz
Tipo per wicd:
git clone https://aur.archlinux.org/wicd-patched
cd wicd-patched/
makepkg -s
sudo pacman -U wicd-patched-1.7.4-1-any.pkg.tar.xz
wicd-curses
Per nuove immagni linux dopo aver ricompilato, per esempio il kernel:
grub-mkconfig -o /boot/grub/grub.cfg
Per il mounting automatico delle chiavette:
udiskie //("udiskie -2 -s&")
---
##TODO LIST:
https://stackoverflow.com/questions/9927217/vim-nerdtree-suddenly-broke
- Capire rete LoredanaDelTe
- Sistemare zsh con tema
- Sistemare NerdTree in vim e installare gli altri plugins
- Keepassx
- Soulseek
- eclipse-jee
- maven

85
docker.md Normal file
View file

@ -0,0 +1,85 @@
#Docker
Altri eseguiti per riprodurre un ambiente trigger farm:
I containers attivi:
docker ps
Tutti I container:
docker ps -a
Le immagini:
docker images
I container sono istanze di un'immagine
Lanciare un'immagine: docker run --name='pippo' -d -i -t -p 57999:7999 -p 58080:8080 targatelematics/triggerfarm2:0.2
Con nome "pippo" esponendo le porte 7999 su 57999 e 8080 su 58080 partendo dall'immagine targatelematics/triggerfarm2:0.2
Mi aggancio ad container attivo di nome "pippo":
docker attach pippo
Faccio in esso modifiche ed esco con exit (lo uccido) oppure CTRL-P CRTL-Q per farne il detach. Per committare le modifiche sull'immagine. Il container è istanza di una precisa immagine, il commit prende il nome del container di cui si vogliono committare le modifiche per cui le modifiche vengono committate su quell'immagine:
docker commit -m "Pulizia dela tmp" -a "Lalo Cura" pippo triggerfarm2:0.3
Per fermare un container:
docker stop pippo
Per avviare un container:
docker start pippo
Poi esistono comandi come pause/unpause/kill/restar applicabili sempre ad un container parimenti ai due precedenti.
Rimozione di un container:
docker rm pippo
Rimozione di tutti i container:
docker rm `docker ps --no-trunc -aq`
Rimozine di un'immagine:
docker rmi triggerfarm2
Build di un'immagine a partire da un Dockerfile utile per iniettare files e comandi ad unimmagine (ATTENZIONE al punto finale). Si da per scontata la presenza del Dockerfile (https://www.digitalocean.com/community/tutorials/docker-explained-using-dockerfiles-to-automate-building-of-images) nella con nome "Dockerfile" nella medesima cartelle da cui si sta eseguendo il comando:
docker build -t "triggerfarm2:0.5" .
Esportare un'immagine
docker save
Esportare un container
docker export
Un file per l'avvio senza passare per systemd o system5 ma eseguendo ad esempio tomcat come primo script:
FROM triggerfarm2:1
CMD nohup /usr/local/tomcat/bin/catalina.sh run
Per collegarsi ad un container (di nome "pippo") attivo in un nuovo tty:
docker exec -it pippo bash
Tecnologia su cui si basa Docker:
https://en.wikipedia.org/wiki/LXC
**Cheatsheet**:
https://github.com/wsargent/docker-cheat-sheet
**Networking**:
https://www.oreilly.com/learning/what-is-docker-networking#example-bridge-mode-networking

242
kong.md Normal file
View file

@ -0,0 +1,242 @@
# Kong
Ref: https://docs.konghq.com/1.0.x/admin-api/
![schema](kong/schema.png "Schema entità principali")
## Servizio (https://docs.konghq.com/1.0.x/admin-api/# service-object)
Il "service" risponde al significato intuitivo di servizio: di fatto definisce *cosa* Kong deve "proxare". Proxa sempre un **upstream** che può essere "virtuale" vedi dopo, oppure è un servizio "reale" ed esterno (Microservice/tomcat/ o altro)
## Rotte (https://docs.konghq.com/1.0.x/admin-api/# route-object)
«Route entities define rules to match client requests. Each Route is associated with a Service, and a Service may have multiple Routes associated to it. Every request matching a given Route will be proxied to its associated Service.»
Le rotte sono entrypoint per i servizi, caturano le richieste e le fanno processare al servizio associato.
Una rotta **non** esiste senza servizio (ne ha sempre al più uno) e un servizio **può** avere più rotte. S (1)<------(\*) R
## Upstream (https://docs.konghq.com/1.0.x/admin-api/# upstream-object)
«The upstream object represents a virtual hostname and can be used to loadbalance incoming requests over multiple services (targets)»
Come riporta la definizione rappresenta la definione di hst virtuale da usare nella definizone di un servizio. In pratica l'*upstream* può esistere senza servizio (anche se questo comporta che non viene usato) ma il servizio lo usa qualora dovesse gestire una chiamata **non** invocando direttamente un (micro) servizio esterno, **ma** un servizio "virtuale" (aka bilanciato).
## Target (https://docs.konghq.com/1.0.x/admin-api/# target-object)
«A target is an ip address/hostname with a port that identifies an instance of a backend service»
Stanno "dietro" agli upstream e ogni upstream può avere più target. si possono aggiungere dinamicamente, **non** possono essere cancellati al più si disabilitano dando loro peso 0.
## Consumer (https://docs.konghq.com/1.0.x/admin-api/# consumer-object)
«The Consumer object represents a consumer - or a user - of a Service»
## Certificate (https://docs.konghq.com/1.0.x/admin-api/# certificate-object)
«A certificate object represents a public certificate/private key pair for an SSL certificate»
## SNI (https://docs.konghq.com/1.0.x/admin-api/# sni-object)
«An SNI object represents a many-to-one mapping of hostnames to a certificate»
In pratica, al presentarsi di una data richiesta servibile alla porta TLS di Kong, è il legame che istruisco Kong su quale certificato usare per servire quella richiesta.
## Creazione del DB
Kong non salva, come invece fa httpd, su FS ma lo fa o su PG o su Cassandra. Questa cosa torna utile perché la clusterizzazione di Kong viene a costo zero (salvo remapping delle porte) indicando il db in comune.
Creazione del db:
```{.graph .center .bash}
CREATE USER kong; CREATE DATABASE kong OWNER kong;
alter user kong with encrypted password 'ubiest';
grant all privileges on database kong to kong;
```
Popolamento e inizializzazione del db:
```{.graph .center .bash}
docker run --rm \
-e "KONG_DATABASE=postgres" \
-e "KONG_PG_HOST=10.255.232.102" \
-e "KONG_PG_PORT=5432" \
-e "KONG_PG_USER=kong" \
-e "KONG_PG_PASSWORD=ubiest" \
-e "KONG_PG_DATABASE=kong" \
-e "KONG_CASSANDRA_CONTACT_POINTS=kong-database" \
-e "KONG_CASSANDRA_CONTACT_POINTS=kong-database" \
kong kong migrations bootstrap
```
Creazione container kong al termine del quale abbiamo Kong funzionante:
```{.graph .center .bash}
docker run -d --name kong \
-e "KONG_DATABASE=postgres" \
-e "KONG_PG_HOST=10.255.232.102" \
-e "KONG_PG_PORT=5432" \
-e "KONG_PG_USER=kong" \
-e "KONG_PG_PASSWORD=ubiest" \
-e "KONG_PG_DATABASE=kong" \
-e "KONG_CASSANDRA_CONTACT_POINTS=kong-database" \
-e "KONG_PROXY_ACCESS_LOG=/dev/stdout" \
-e "KONG_ADMIN_ACCESS_LOG=/dev/stdout" \
-e "KONG_PROXY_ERROR_LOG=/dev/stderr" \
-e "KONG_ADMIN_ERROR_LOG=/dev/stderr" \
-e "KONG_ADMIN_LISTEN=0.0.0.0:8001, 0.0.0.0:8444 ssl" \
-p 48000:8000 \
-p 48443:8443 \
-p 48001:8001 \
-p 48444:8444 \
kong
```pandoc kong.md --listing -H listing-setup.tex -o kong.pdf --highlight-style=espresso
# konga
Comandi per la creazione di konga. Al primo accesso dopo aver impostato username e password va impostata graficamente l'istanza Konga cui appoggiarsi.
docker pull pantsel/konga
docker run -p 41337:1337 --name konga \
-e "NODE_ENV=production" \
-e "TOKEN_SECRET=t1z1@n0f3rr031s3tt3n@n1" pantsel/kong
## Clustering
Kong è in grado di scalare orizzontalmente e la configurazione del cluster è implicita nel lanciare una nuova istanza condividendo con le precedenti il database PG (o Cassandra). Esistono delle configurazioni settabili tramite variabili d'ambiente di modo da fare tuning su politiche di caching e propagazione.
Una seconda istanza, testata all'interno del medesimo dockerd cambiandone le porte per ovvie ragioni, potrebbe, ad esempio, essere lanciata così:
```{.graph .center .bash}
docker run -d --name kong2 \
-e "KONG_DATABASE=postgres" \
-e "KONG_PG_HOST=10.255.232.102" \
-e "KONG_PG_PORT=5432" \
-e "KONG_PG_USER=kong" \
-e "KONG_PG_PASSWORD=ubiest" \
-e "KONG_PG_DATABASE=kong" \
-e "KONG_CASSANDRA_CONTACT_POINTS=kong-database" \
-e "KONG_PROXY_ACCESS_LOG=/dev/stdout" \
-e "KONG_ADMIN_ACCESS_LOG=/dev/stdout" \
-e "KONG_PROXY_ERROR_LOG=/dev/stderr" \
-e "KONG_ADMIN_ERROR_LOG=/dev/stderr" \
-e "KONG_ADMIN_LISTEN=0.0.0.0:8001, 0.0.0.0:8444 ssl" -p 58000:8000 -p 58443:8443 -p 58001:8001 -p 58444:8444 kong
```
## Load balancing
il LB tra istanze diverse i Kong DEVE essere fatto da un bilanciatore posto a monte come avviene per Apache httpd
## Load Balancing internal
## # Prerequisiti per testare
Definire due servizi FAKE con netcat: questi simulano uno stupidissimo WEB server
in as01 lanciare:
```{.graph .center .bash}
while true; do (echo -e 'HTTP/1.1 200 OK\r\n'; echo -e "\n\tMy website has date function AS01" ; echo -e "\t$(date)\n") | nc -lp 8080; done
```
in CS01 lanciare:
```{.graph .center .bash}
while true; do (echo -e 'HTTP/1.1 200 OK\r\n'; echo -e "\n\tMy website has date function CS01" ; echo -e "\t$(date)\n") | nc -lp 8080; done
```
In questo modo abbiamo due server in ascolto sulla 8080 delle due macchine (10.255.232.101 e 10.255.232.102). Sotto verranno usate per deinire i target
```{.graph .center .bash}
curl -X POST http://lb.mopar.vpn:48001/upstreams \
--data "name=lb.fake.mopar.vpn"
```
Il "data" sopra specificato è come definire un virtual host che va usato nei comandi dopo . In ltre parole il "name" con cui si definisce l'upstream è lasciato liberamente definibile dall'utente PURCHE' po si usi uguale nella definizione del servizio (vedi dopo)
# add two targets to the upstream
Queste istruzioni indicano come il virtualhost sopracitato deve invocare i servizi sottesti e con quali pesi
```{.graph .center .bash}
curl -X POST http://lb.mopar.vpn:48001/upstreams/lb.fake.mopar.vpn/targets \
--data "target=10.255.232.101:8080"
--data "weight=100"
```
```{.graph .center .bash}
curl -X POST http://lb.mopar.vpn:48001/upstreams/lb.fake.mopar.vpn/targets\
--data "target=10.255.232.102:8080"
--data "weight=50"
```
# create a Service targeting the Blue upstream
ATTENZIONE: qui l'host DEVE matchare il "name" specificato nella definizione dell'upstream
```{.graph .center .bash}
curl -X POST http://lb.mopar.vpn:48001/services/ \
--data "name=address-service" \
--data "host=lb.fake.mopar.vpn" \
--data "path=/"
```
# finally, add a Route as an entry-point into the Service
```{.graph .center .bash}
curl -X POST http://lb.mopar.vpn:48001/services/address-service/routes/ \
--data "hosts[]=ghesboro
```
Le rotte sono fondamentali specificando gli host a cui deve rispondere ho due alternative:
1) apache way: bastapresentartsi con quell'host come dominio
2) ci si puà presentare con qualunque dominio (anche l'ip) MA bisogna specificare nell'header "Host" il valore con cui si è definito l'host nella rotta. MOLTO UTILE quando si vuole testare una configurazione senza per forza aver definito gli host su DNS e/o /etc/hosts
Altra ipotesi da noi già utilizzata via apache è che la discriminante sia il path
```{.graph .center .bash}
curl -i -X GET \
--url http://lb.mopar.vpn:48000/ \
--header 'Host: ghesboro'
```
LA discriminante è l'header se invece modifico una rotta elimnano l'header. E' nelle rotte che si agisce per capire COME gestire la chiamata. Oltre al routing via host header.
Abbiamo che la possibilità di fare un routing da path.
Considerazioni generali:
non serve che il server ospitante kong abbia definiti lb.fake.mopar.vpn nei suo host/DNS
## Certificates
Si carica chiave e foglia poi è l'SNI (tollroad.stage.mopar.vpn) che fa il matching tra richiesta entrante nella porta SSL (48443 negli esempi sopra) e certificato da usare. **ATTENZIONE** non sembra accettare "wildchars" ma c'è una pull request "validata" e accettata per implementarne il supporto per cui probabilmente verranno supportate.
## Rotte e RegEx
E' possibile creare rotte più specificative che, *probabilmente* (aka da verificarsi), verranno pioriticizzate in base alla loro lunghezza. Nell'incertezza nella loro definizone esiste un attributo priorità. Serve per esempio se, proxato tutto T2, vogliamo catturare solo certe richieste di alcuni path più specificativi, tipo public API, per poterci applicare dei plugin di rate limiting.
Per i path params che ovviamente variano nel path, è possibile applicare, nella definizione della rotta, delle espressioni regolari
## Su alcuni parametri di Konga (e Kong)
- **Strip Path**: serve per torgliere il path specificato nella root nel momento in cui si proxa la richiesta. Se metto "/t2" nella root e dietro l'upstream ha context path "/t2" *senza* lo **Strip Path** mi ritorovo un "/t2t2" nella richiesta processata che ovviamente mi da un 404
- **Preserve host**: se la richiesta originaria è "stage.ubiest.com/t2" e **Preseve host** è "off" allora nel browser l'indirizzo verrà sostituito con l'indirizzo IP "interno" proxato
## Consumers e api-key (https://docs.konghq.com/1.0.x/getting-started/enabling-plugins/)
Serve per identificare un utente (aka consumer) con una apikey
1) creare un concumer via Konga e associare ad esso sotto la tab credentials una apikey
2) "proteggere" un servizio con apikey:
```
curl -i -X POST \
--url http://10.255.232.103:48001/services/TollRoad/plugins/ \
--data 'name=key-auth'
```
Così facendo sollo il campo "key_names" del servizio viene asseganto di default "apikey" che è la chiave passata come header o in query string sotto cui settare l'apikey del cunsumer. Se si fa via Konga occorre invece specificare esplicitamente almeno un valore per il "key_names"
## Metriche
Prometheus ... to be continued
## Censimento via API della app registrate in eureka per popolamento via script
curl --url http://localhost:18761/eureka/apps | grep instanceId

Binary file not shown.

After

Width:  |  Height:  |  Size: 16 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 334 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 197 KiB

Binary file not shown.

BIN
kong/get-kong-api.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 39 KiB

37
kong/poc.md Normal file
View file

@ -0,0 +1,37 @@
" Press ? for help
.. (up a dir)
/home/conte/Documenti/appunti/
▾ kong/
5nszenm2bcqu0gae134h.png
BEP_Kong_Becoming-a-King-of-PI-Gateways.jpg
BEP_Kong_Becoming-a-King-of-PI-Gateways.png
BEP_Kong_Becoming-a-King-of-PI-Gateways.xcf
get-kong-api.png
schema.png
▸ suono/
395test_TO_DELETE_DOPO_05.2018.txt
appunti_migraizone.md
appunti_postgres.md
appunti_rammitmq.md
appunti_rammitmq_2.md
arch.md
certificati_ssl.md
container_od.md
docker.md
dr.md
installazioni_base_centos.md
kong.md
kong.pdf
linux_tips.md
listing-setup.tex
mopar.md
MOPAR_release_notes
nokia.md
oracle_DBA.sql
rip_al_futuro.md
springBoot.md
sso.md
sso_ping_appunti.md
synths_diy.md
synths_diy.pdf

BIN
kong/schema.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 177 KiB

Binary file not shown.

Binary file not shown.

Binary file not shown.

BIN
suono/synth.pdf Normal file

Binary file not shown.

96
synths_diy.md Normal file
View file

@ -0,0 +1,96 @@
#Sintetizzatori
I Sintetizzatori analogici ma anche i più moderni Virtual Synth, sono costituiti da varie sezioni, ognuna con compito ben preciso per la generazione del suono.
Vediamoli in dettaglio:
##Sezione VCO
**Il Voltage Controlled Oscillator è la sezione in cui vengono generate le forme d'onda: sinusoidale, quadra, triangolare, a dente di sega, che danno origine a suoni con caratteristiche molto differenti tra loro.**
**L'onda sinusoidale è la base per la produzione di ogni suono**: una sinusoide infatti corrisponde ad una sola frequenza.
**La forma d'onda triangolare** è viene utilizzata per generare sonorità calde quali i pad o tappeti.
**L'onda quadra** ha un suono cupo e marcato e viene utilizzata per generare suoni che emulano l'oboe e il clarinetto, ma anche synth lead.
**L'onda rettangolare** è dotata del parametro Pulse Width che regolato al 50% si trasforma in quadra.
**L'onda a dente di sega** è utilizzata per emulare il timbro degli ottoni, i lead, bassi e pad.
##Sezione VCF
**Il Voltage Controlled Filter, filtra il suono in ingresso eliminando componenti armoniche (frequenze) tramite due parametri: la cutoff frequency e la resonance.**
Il primo (frequenza di taglio) rappresenta una soglia oltre la quale le frequenze vengono attenuate; quelle inferiori sono lasciate inalterate.
La resonance serve a enfatizzare le frequenze intorno a quella di taglio.
Il tipo di filtro descritto è detto passa-basso.
Ne esistono di altri tipi e sono:
+ *Filtro passa-alto taglia le frequenze inferiori alla soglia e lascia passare quelle superiori.*
+ *Filtro passa-banda taglia le frequenze "laterali" (utilizza due frequenze di taglio).*
+ *Filtro a reiezione di banda esclude un intervallo di frequenze e consente il passaggio delle altre.*
+ *Filtro Multimodo in grado di lavorare in più modalità.*
##Sezioni VCA
**Il Voltage Controlied Amplifier, è la sezione finale di un sintetizzatore.**
In esso confluisce il segnale generato dagli oscillatori e filtrato dai VCF.
**Qui viene controllata l'ampiezza del suono in uscita.**
**Lavora assieme la sezione inviluppo per gestire l'andamento nel tempo dell'amplificazione del segnale.**
**L' inviluppo classico è l'ADRS:**
A - attacco del segnale
D - decadimento dell'attacco del segnale
R - rilascio del segnale
S - sostegno del segnale
##Sezione LFO
**La sezione Low Frequency Oscillator, è oscillatore a bassa frequenza (sotto i 15Hz) che applicati ad un parametro del VCF o VCA ne determinano variazioni periodiche nel tempo (modulazioni) con frequenza impostabile.**
L' LFO dispone delle stesse forme d'onda di un VCO e aggiunge quella casualità che genera un andamento discontinuo e casuale alla modulazione.
---
##Repo
Censimento/lista di tutti i programmi/libreria di produzione musicale sotto linux: https://github.com/nodiscc/awesome-linuxaudio
kxstudio
ELnk (linux based music Operating system) https://www.mindmusiclabs.com/
##Synths DIY
https://www.muffwiggler.com/forum/viewtopic.php?t=90426&sid=8b0818f54cd6013cceabc76f5002fece
http://electro-music.com/forum/topic-42357.html&postorder=asc
http://randomsource.net/haible/eurorack
http://yusynth.net
Ma soprattutto: http://yusynth.net/index_en.php?&arg=6
https://shop.musicfromouterspace.com/cart/
Materiale DIY Eurorack: https://www.exploding-shed.com/
Materiale per case: http://store.synthrotek.com/
PCB e kits moduli http://www.elby-designs.com/webtek/cgs/cgs.htm
##Materiale teorico
+ https://www.hackmeeting.org/hackit10/presentazioni/synth.pdf
+ http://www.controlvoltage.org/images/Il%20sintetizzatore%20analogico%20-%202014.pdf
##Posti in cui comprare
+ https://shop.befaco.org sho ufficiale di casa Befaco con tutti i suoi DIY Kit
+ https://www.thonk.co.uk negozio inglese figo soprattuto per la vendita di numero DIY Kits

78
vim_it.md Normal file
View file

@ -0,0 +1,78 @@
#(G)VIM appunti a spruzzo
Propedeutico per il camelcase da campo DB. Trasforma gli “_” seguiti da lettra minuscola in lettera maiuscola dopo lunderscore:
:s/_\([a-z]\)/\U\1/g
Camelcase
http://vim.wikia.com/wiki/Converting_variables_to_or_from_camel_case
Prima tutto in undercase von “V~” sulla linea
poi
:s/_\(\w\)/\U\1/g
iIl viceversa da campo java a campo DB eseguire prima linserimento degli underscores
:s/\([A-Z]\)/_\1/g
Poi luppercase di tutto:
:s/\(.*\)/\U\1/g
Usare i numeri di riga nelle espressioni:
%s/###/\=line(".")/g
## Correzione ortografica
Orginale qui:
<https://robots.thoughtbot.com/vim-spell-checking>
o qui:
<http://vimdoc.sourceforge.net/htmldoc/spell.html#spell-quickstart>
per attivare
:setlocal spell
per attivare specificando un dizionario
:setlocal spell spelllang=en_us
A questo punto potrebbe venir notificato che il file di vocabolario .spl non è
presente, dovrebbe scaricarlo automaticamente altrimenti va scaricato
manualmente da qui:
<http://ftp.vim.org/pub/vim/runtime/spell/>
salvato sotto la cartella "spell" di ".vim"
Per abilitare lo spellchacking automaticmanete su tutti i file md (per esempio) in .muttrc [DA TESTARE:]:
autocmd BufRead,BufNewFile *.md setlocal spell
Per cambiare i colori con cui vengono evidenziati gli errori
hi SpellBad ctermfg=015 ctermbg=000 cterm=none guifg=#FFFFFF guibg=#000000 gui=none
dentro gui è possibile specificare delle stilizzazioni tipo underline, bold
Se si volesse saltare da errore a errore evidenziato ( <http://vimdoc.sourceforge.net/htmldoc/spell.html#spell-quickstart> ):
next: "**]s**" e previous "**[s**" con "**z=**" ottengo i suggerimenti di
correzione da parte del vocabolario impostato con i comandi sopra
## Beautyfiers
Per xml, installare xmllint (libxml2-utils) ed eseguite *dopo aver selezionato il testo da formattare*:
!xmllint --format -
Se selezionato il testo la riga di comando inizia con “'<,'>” tali caratteri vanno mantenuti e il comano xmllint va accosato a quanto riporta la riga di comando. Conseguentemente lesecuzione in versione finale del comando:
'<,'> !xmllint --format -
per json (da verificare):
:%!python -m json.tool
## Wrapping
Eisgenza iniziale era, in fase di stsura di documenti Markdown, di wrappare le
righe dopo *n* caratteri (tipicamente 80).
Per abilitare la funzione automagicamente:
:set textwidth=80
Per riformattare il testo già scritto:
"**gq**" dopo aver selezionato il testo da riformattare