Several ways to get metadata (like ip address) when you're connected to an EC2:
/opt/aws/bin/ec2-metadata
Je me mets ça de côté pour gagner du temps la prochaine fois
logfile=/tmp/logfile.log
errorfile=/tmp/error.log
function log() {
echo -e "\e[34m\e[1m[$(date +%Y-%m-%d) $(date +%H:%M:%S)] $1\e[0m" | tee -a /tmp/logfile.log
}
function logerror() {
echo -e "\e[91m\e[1m[$(date +%Y-%m-%d) $(date +%H:%M:%S)] $1\e[0m" | tee -a /tmp/logfile.log
}
log "prout"
logerror "pwet"
Create a new file, curl-format.txt, and paste in:
time_namelookup: %{time_namelookup}\n
time_connect: %{time_connect}\n
time_appconnect: %{time_appconnect}\n
time_pretransfer: %{time_pretransfer}\n
time_redirect: %{time_redirect}\n
time_starttransfer: %{time_starttransfer}\n
----------\n
time_total: %{time_total}\n
Make a request:
curl -w "@curl-format.txt" -o /dev/null -s "http://wordpress.com/"
I don't know if this shit is expected (normal behaviour or not) but this is annoying
bash :
$ toto=tata
$ echo $toto
tata
$ toto='tata'
$ echo $toto
tata
$ toto="tata"
$ echo $toto
tata
avec docker run -e
$ docker run -e toto=tata -it debian:jessie bash
root@5de64152ed05:/# echo $toto
tata
$ docker run -e toto='tata' -it debian:jessie bash
root@99a6b62f595c:/# echo $toto
tata
$ docker run -e toto="tata" -it debian:jessie bash
root@ab7581c30734:/# echo $toto
tata
avec docker run --env-file:
$ cat env.file
toto="tata"
$ docker run -it --env-file env.file debian:jessie bash
root@805480de4a52:/# echo $toto
"tata"
$ cat env.file
toto='tata'
$ docker run -it --env-file env.file debian:jessie bash
root@004b88cc448d:/# echo $toto
'tata'
$ cat env.file
toto=tata
$ docker run -it --env-file env.file debian:jessie bash
root@2ca9908d1cdf:/# echo $toto
tata
avec docker compose:
$ cat docker-compose.yml
version: '2'
services:
foo:
image: debian:jessie
container_name: foo
environment:
docker-compose up -d
docker exec -it foo bash
root@71a9a886cc24:/# echo $toto1
tata
root@71a9a886cc24:/# echo $toto2
"tata"
root@71a9a886cc24:/# echo $toto3
'tata'
TIL
Beanstalk is a little bit... magic. Dunno yet if its good or not :
Elastic Beanstalk creates log volumes on the container instance, one for each container, at /var/log/containers/containername. These volumes are named awseb-logs-containername and should be mounted to the location within the container file structure where logs are written.
For example, the following mount point maps the nginx log location in the container to the Elastic Beanstalk–generated volume for the nginx-proxy container.
{
"sourceVolume": "awseb-logs-nginx-proxy",
"containerPath": "/var/log/nginx"
}
And all this logs can be copied into s3 automagically: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-options-general.html#command-options-general-elasticbeanstalkhostmanager
Via Doo
20h d'autonomie annoncée pour celui là :
Lenovo ThinkPad X270
Le Lenovo ThinkPad X270 est conçu pour durer. Grâce à sa batterie, il pourra en effet tenir pas moins de 20 heures avec une seule charge. Son châssis a aussi été renforcé pour lui permettre de résister aux chocs.
Plusieurs configurations seront proposées. L’écran de 12,5 pouces pourra aussi afficher du 720p ou du 1080p. Derrière, on pourra opter pour des Intel Core iX couplés à un maximum de 16 Go de RAM. Côté stockage, Lenovo proposera des disques à plateau (2 To max) ou du SSD (512 Go max). Il faudra cependant se contenter d’un GPU intégré.
Le prix sera fixé à 949 $ pour le modèle de base.
Sympa les petites nouveautés!
docker system df
docker system prune
CLI restructured <3
Improved CLI backwards compatibility <3
cat <<'EOF' >> /tmp/bar
foo
EOF
cat <<EOF >> /tmp/bar
$foo
EOF
Dashing n'est plus maintenu, voici son fork, Smashing!
Compose file version 2.1 and up
Healthcheck configuration can now be done in the service definition using
the healthcheck parameter
Containers dependencies can now be set up to wait on positive healthchecks
when declared using depends_on. See the documentation for the updated
syntax.
Stateless auth for rest api
Query Authentication
All REST queries must be authenticated by signing the query parameters sorted in lower-case, alphabetical order using the private credential as the signing token. Signing should occur before URL encoding the query string.
In other words, you don't pass the shared secret component of the API key as part of the query, but instead use it to sign the query. Your queries end up looking like this:
GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789
The string being signed is "/object?apikey=Qwerty2010×tamp=1261496500" and the signature is the HMAC-SHA256 hash of that string using the private component of the API key.
The main objection to this approach is that the private API key devolves into a kind of password for static calls. For example, if the query were instead:
GET /object?apiKey=Qwerty2010
The signature would be the same every time you made that specific query. However, you are using SSL, right? Furthermore, adding in a timestamp makes each query differ. For extra security, you can make the timestamp a more formal date-time value with time zone information and disallow queries outside of the query range.
The real controversy is whether signing should occur before or after URL encoding values. There is no "right" answer. I lean towards signing before encoding because most programming tools make it easier on the server side to get the unencoded values versus the encoded values. I'm sure good arguments can be made the other way. What I really care about is this: let's pick one and stick with it.
Je ne connaissais pas du tout ce projet qui est bien interessant..
Surtout le module bank qui a l'air très actif
Je garde ça sous le coude, ça pourrait m'être utile dans mon application de gestion de compte