rabbimq-server on lx branded zone

Hi,
I’m playing with Sensu in SmartOS LX zone

imgadm avail | grep 23ee2dbc-c155-11e6-ab6d-bf5689f582fd

23ee2dbc-c155-11e6-ab6d-bf5689f582fd centos-7 20161213 linux lx-dataset 2016-12-13
root@d8-cb-8a-bf-92-f0 ~ # imgadm info 23ee2dbc-c155-11e6-ab6d-bf5689f582fd
{
“manifest”: {
“v”: 2,
“uuid”: “23ee2dbc-c155-11e6-ab6d-bf5689f582fd”,
“owner”: “00000000-0000-0000-0000-000000000000”,
“name”: “centos-7”,
“version”: “20161213”,
“state”: “active”,
“disabled”: false,
“public”: true,
“published_at”: “2016-12-13T16:56:50Z”,
“type”: “lx-dataset”,
“os”: “linux”,
“files”: [

{
“sha1”: “57e381704ced765d7ed19ad11efc04d521f608ed”,
“size”: 261271891,
“compression”: “gzip”
}
],
“description”: “Container-native CentOS 7.3 64-bit image. Built to run on containers with bare metal speed, while offering all the services of a typical unix host.”,
“homepage”: “https://docs.joyent.com/images/container-native-linux”,
“requirements”: {
“networks”: [
{
“name”: “net0”,
“description”: “public”
}
],
“min_platform”: {
“7.0”: “20160317T000105Z”
},
“brand”: “lx”
},
“tags”: {
“role”: “os”,
“kernel_version”: “3.10.0”
}
},
“zpool”: “zones”,
“source”: “https://images.joyent.com”
}

The  Sensu documentation  tell us how to install rabbitmq-server  and all is working as expect. I was in trouble just with
systemctl restart rabbitmq-server
The command after a lot of time answer me with error 🙁     After google-ing I have to use my resource.

Systemd call rabbitmq-server.service ?

[root@sensu01 ~]# systemctl status rabbitmq-server -l
● rabbitmq-server.service – RabbitMQ broker
Loaded: loaded (/usr/lib/systemd/system/rabbitmq-server.service; enabled; vendor preset: disabled)
Active: active (running) since Thu 2017-04-20 17:39:51 UTC; 2min 51s ago
Process: 6672 ExecStop=/usr/sbin/rabbitmqctl stop (code=exited, status=0/SUCCESS)
Main PID: 7131 (rabbitmq-server)
CGroup: /system.slice/rabbitmq-server.service
├─7131 /bin/sh -e /usr/lib/rabbitmq/bin/rabbitmq-server
├─7361 /usr/lib64/erlang/erts-8.3/bin/beam.smp -W w -A 128 -P 1048576 -t 5000000 -stbt db -zdbbl 32000 -K true -B i — -root /usr/lib64/erlang -progname erl — -home /var/lib/rabbitmq — -pa /usr/lib/rabbitmq/lib/rabbitmq_server-3.6.9/ebin -noshell -noinput -s rabbit boot -sname rabbit@sensu01 -boot start_sasl -config /etc/rabbitmq/rabbitmq -kernel inet_default_connect_options [{nodelay,true}] -sasl errlog_type error -sasl sasl_error_logger false -rabbit error_logger {file,”/var/log/rabbitmq/rabbit@sensu01.log”} -rabbit sasl_error_logger {file,”/var/log/rabbitmq/rabbit@sensu01-sasl.log”} -rabbit enabled_plugins_file “/etc/rabbitmq/enabled_plugins” -rabbit plugins_dir “/usr/lib/rabbitmq/plugins:/usr/lib/rabbitmq/lib/rabbitmq_server-3.6.9/plugins” -rabbit plugins_expand_dir “/var/lib/rabbitmq/mnesia/rabbit@sensu01-plugins-expand” -os_mon start_cpu_sup false -os_mon start_disksup false -os_mon start_memsup false -mnesia dir “/var/lib/rabbitmq/mnesia/rabbit@sensu01” -kernel inet_dist_listen_min 25672 -kernel inet_dist_listen_max 25672
├─7537 erl_child_setup 65536
├─7625 inet_gethost 4
└─7626 inet_gethost 4
‣ 7131 /bin/sh -e /usr/lib/rabbitmq/bin/rabbitmq-server

So first I check if  /usr/lib/rabbitmq/bin/rabbitmq-server is working on CLI and yes it works.
What’s in /usr/lib/systemd/system/rabbitmq-server.service
[root@sensu01 ~]# cat /usr/lib/systemd/system/rabbitmq-server.service
[Unit]
Description=RabbitMQ broker
After=syslog.target network.target
[Service]
Type=notify
User=rabbitmq
Group=rabbitmq
WorkingDirectory=/var/lib/rabbitmq
ExecStart=/usr/sbin/rabbitmq-server
ExecStop=/usr/sbin/rabbitmqctl stop
NotifyAccess=all
TimeoutStartSec=3600
[Install]
WantedBy=multi-user.target

And I found that Type=notify

<<Behavior of notify is similar to simple; however, it is expected that the daemon sends a notification message via sd_notify(3) or an equivalent call when it has finished starting up. systemd will proceed with starting follow-up units after this notification message has been sent. If this option is used, NotifyAccess= (see below) should be set to open access to the notification socket provided by systemd. IfNotifyAccess= is missing or set to none, it will be forcibly set to main. Note that currently Type=notify will not work if used in combination with PrivateNetwork=yes.>>

But we are inside a lx smartos zone so can be some mismatching  between system call  – in this case I’d like to know dtrace, but not until at the moment-

I change the  Unit section in rabbitmq-server.service

from

Type=notify
NotifyAccess=all

to

Type=simple
#NotifyAccess=all

In the end systemctl restart rabbitmq-server is working as expect

Podcast of Bryan Cantrill – Persistence and Action

Bryan’s top 3 tips for delivering more value:
  1. Read more
  2. Write more
  3. Be persistent

 

Il QoS di ZeroShell mediante il generatore di traffico Ostinato


Ciao,

 Analisi del QoS di ZeroShell mediante il generatore di traffico Ostinato

ps.

si accettano suggerimenti e correzioni.

 

Devo ringraziare  il Network Traffic Generator and Analyzer Ostinato che mi ha dato la possibilità di comprendere meglio il QoS.

Di seguito riporto lo schema hw per i test.

 

upgrade the 64-bit tools set (SamrtOS GZ) 2016Q3

Hi,

if you need to update pkgsrc on GZ

  1. read the documentation https://pkgsrc.joyent.com/install-on-illumos/

but today (10 october) I found some error on my global zone “Live Image”: “20160929T025934Z”,

 

root@d8-cb-8a-bf-92-f0 ~ # pkg_add -U pkgin
SSL support disabled
pkg_add: Can't process https://pkgsrc.joyent.com:443/packages/SmartOS/2016Q3/tools/All/pkgin*: Not owner
pkg_add: no pkg found for 'pkgin', sorry.
pkg_add: 1 package addition failed

 

  1.  wget https://pkgsrc.joyent.com/packages/SmartOS/2016Q3/tools/All/pkgin-0.9.4nb3.tgz --no-check-certificate
  2.  wget https://pkgsrc.joyent.com/packages/SmartOS/2016Q3/tools/All/libarchive-3.2.1nb2.tgz --no-check-certificate
  3.  pkg_add -u ./libarchive-3.2.1nb2.tgz
  4.  pkg_add -u ./pkgin-0.9.4nb3.tgz
  5.  pkgin update
  6.  pkgin full-upgrade

 

now I can install software into Global Zone 😉

 

 

SmartDataCenter and coal-setup

Hi,

“Cloud on a Laptop”  in progress 🙂  I’d like to check  so my  “man is” :

https://github.com/joyent/sdc/blob/master/docs/developer-guide/coal-setup.md

 

 

 

Link Status Monitor ….a tribute

LSM – Link Status Monitor

LSM è un “Link Status Monitor” che può essere usato per controllare ad esempio  la connettività di un router/firewall Linux  e se accade di avere delle connessione multiple, LSM  può  cambiare il routing a seguito di un evento up/down mediante uno script esterno.

Quando un segnale  SIGUSR1 è ricevuto lo stato attuale della connessione è inviata al syslog.

Questo software è fortemente influenzato da fping e da iputils  arping. Un grande riconoscimento gli va dato per i loro lavoro.

LICENSE

GPLv2, tu sarai in grado di trovare la  GNU Public License 2.0 in  www.gnu.org.

DECISION MAKING

Nella vesione 0.27 di lsm , l’algoritmo di  “detection” lavora in questo modo:

LSM tiente traccia di

1) il risultato dei più recenti ping ( sino a 100).

2) il numero di consecutivi ping persi .

3) il numero consecutivo di ping ricevuti .

Sia  A == al numero di ping recentemente persi

Sia  B == al numero di ping consecutivi persi

Sia C == al numero di ping consecutivi ricevuti

 Se la connessione ( o il gruppo di connessioni) è UP

AND ( (A >= max_packet_loss) OR (B >= max_successive_pkts_lost) allora cambio la connessione ( o il gruppo di connessioni) in down .

Altrimenti se la connessione (o il gruppo di connessioni) è DOWN

AND ( (A <= min_packet_loss) AND (C > min_successive_pkts_rcved) ) allora cambio la connessione ( o il gruppo di connessioni) in up.

Nota: LSM assume che ogni connessione è in uno stato iniziale “sconosciuto”.

AUTHORS

Mika Ilmaranta <ilmis at nullnet.fi>

DOWNLOADS

Download directory.

MAILING LIST

LSM mailing list subscription


LSM in action – Link Status Monitor in action

Hi,

this link http://lsm.foobar.fi/  solved my problem.

 

%description
Lsm is the link status monitor.

Lsm can ping multiple targets and when up or down event happens
it will execute user configured external script so it can be used
as poor man's routing protocol.

 

 

 

|LB1|10.10.10.1
———————-<—-(one o more client with LSM onboard)
|LB2|10.10.10.2

 

so when one load balancer  is down  lsm exec a little script in /usr/libexec/lsm/

In my case just down is the “case”

#!/bin/bash -x
#put all output into file
 echo "$@" >/var/log/lsm.log
# what is my default router ?
 DEFAULT_R=$(ip route show to exact 0.0.0.0/0  | awk '{ print $3 }')
#if  the status  is down and that is just my default router  then I change it with the new one
 # otherwise if is up just logger :-)
if [ $1  == "down" ] && [ $3 == "${DEFAULT_R}" ]
 then
 logger  "ip route replace default via 10.10.10.1 dev eth0"
 ip route replace default via 10.10.10.1 dev eth0
 elif [ $1 == "up" ]
 then
 logger "$@"
 fi

English lesson is over.

The end …. another link to see LSM in action is http://shorewall.net/MultiISP.html#lsm

 

 

Ciao,

come ringraziare chi mi ha risolto il problema, semplice lo pubblico in modo che altri possano averne lo stesso beneficio che ne ho avuto io.

 

Premessa.

Il problema si presenta quando abbiamo due o più server che fanno da gateway ad una batteria di server alle loro spalle.  Sappiamo che il default gateway nella rete è l’ultima risorsa che è presente nella tabella di routing. In rete possiamo trovare molta documentazione sul “policy routing” e tutti partono dal presupposto di avere due interfacce di rete con due indirizzamenti differenti a cui poi far puntare i due default gateway. Nel mio caso non ho la necessità di avere due indirizzamenti diversi ma poichè gioco in un ambiente virtuale mi posso permettere di avere due server che fungono da default gateway per la stessa sottorete. Tanto loro non lo sanno 🙂  ma dobbiamo farlo sapere ai server che li usano. Altra fortuna è data dal fatto che i server dietro i  due server  gateway sono anche loro sulla stessa sottorete e quindi anche in caso di down di uno dei due riescono sempre a raggiungere il nodo up, proprio perché “parlano” a livello due. Ora LSM entra in gioco sui server che usano i due lb come gateway. LSM restituisce al cambio di stato la seguente stringa

up server-lb1 10.10.10.1 eth0 support@example.com 96 4 5 1 94 0 0 31425 10.10.10.3 down 1459592375

${STATE}  ${NAME} ${CHECKIP}  ${DEVICE}  ${WARN_EMAIL}  SOME_STATISTICS ${SRCIP} ${PREVSTATE}  OTHER_STATISTICS

Di questa stringa ho usato il  $1=STATE e $CHECKIP che ho passato allo script che richiama LSM per impostare il nuovo gateway. La logica è la seguente:

trovo il default gateway del server dove viene eseguito LSM e poi se lo stato della connessione – che ho fatto coincidere con un gateway – è down paragono il  ${CHECKIP} con il default gateway e se questi coincidono è il caso che lo cambio con quello che ipotizzo UP.

 

#!/bin/bash -x
#put all output into file
 echo "$@" >/var/log/lsm.log
# what is my default router ?
 DEFAULT_R=$(ip route show to exact 0.0.0.0/0  | awk '{ print $3 }')
#if  the status  is down and that is just my default router  then change it with the new one
 # otherwise if is up just logger :-)
if [ $1  == "down" ] && [ $3 == "${DEFAULT_R}" ]
 then
 logger  "ip route replace default via 10.10.10.1 dev eth0"
 ip route replace default via 10.10.10.1 dev eth0
 elif [ $1 == "up" ]
 then
 logger "$@"
 fi

 

 

La condizione che tutti i gateway siano DOWN porterebbe i nodi ad un ping pong continuo, la condizione la possiamo mitigare inserendo un “sleep 30” al termine del “ip route replace” . Perchè dico mitigare, se tutto è giù allora il problema è  grave e mi devo solo preoccupare di non sovraccaricare il server con un loop infinito di “ip route  replace”

 

 

 

 

 

io tuta blu

N E T T O DEL M E S E

1.588,00€

Io speriamo che me la cavo

Ciao,

questo post è  così !

 

Joyent’s Triton at Barton’s Blog

Intro: Setting up Joyent’s Triton in Dell’s CTO lab; post 1

The platform supporting Joyent’s Triton in Dell’s CTO lab – post 2

Installation details for Joyent’s Triton in Dell’s CTO lab; post3