Mit diesem Befehl kann man nach yum Packeten suchen:
yum search mysql | grep client
Mit diesem Befehl kann man nach yum Packeten suchen:
yum search mysql | grep client
Um eine csv-Datei zu erstellen, in der die Umlaute richtig kodiert sind, muss man in seinem Projekt, welches im Normalfall UTF-8 kodiert ist, die Umlaute nach UTF-16LE kodieren. Diese Kodierung kann von Windows und Mac angezeigt werden.
$file = fopen('file.csv', 'w'); foreach ($rows as $row) { $row = array_map(function($cell){ return mb_convert_encoding($cell, 'UTF-16LE', 'UTF-8'); }, $row); fputcsv($file, $row, ';'); } fclose($file);
Damit die Logs schön formatiert aus einer Symfony 4 Anwendung in AWS Cloudwatch ankommen, muss man Monolog folgendermaßen konfigurieren:
# config/services.yaml Monolog\Formatter\JsonFormatter: calls: - [includeStacktraces]
und
# config/packages/prod/monolog.yaml monolog: handlers: main: type: stream level: error path: '%kernel.logs_dir%/error.log' formatter: Monolog\Formatter\JsonFormatter
Danach muss man der Cloudwatch Daemon konfigurieren:
# /etc/awslogs/awslogs.conf
[general] # Path to the CloudWatch Logs agent's state file. The agent uses this file to maintain # client side state across its executions. state_file = /var/lib/awslogs/agent-state [/var/www/html/var/log/error.prod.log] datetime_format = [%Y-%m-%d H:%M:%S] file = /var/www/html/var/log/error.log buffer_duration = 5000 log_stream_name = {instance_id} initial_position = start_of_file log_group_name = test_group_name/error_log
und man erhält wunderbare (aggregierte) ErrorLog Informationen in Cloudwatch Logs Insight:
Bei meiner Arbeit mit Cloudfromation habe ich viel nützliche Tipps gesammelt, die ich gern teilen will.
Für die Jetbrains IDEs wie PHPStorm, Webstorm oder IntelliJ gibt es ein sehr gutes AWS Cloudfromation Plugin namens AWS Cloudfromation von Leonid Shalupov:
Dieses biete Autocomplete für die IDE an und eine automatische Formatüberprüfung, ob Attribute gesetzt werden, die dort nicht erlaubt sind. Auf diesem weg kann man viele Fehler schon vor dem validieren finden und spart viel Zeit.
Damit eine Instanz neu neugestartet wird, nachdem die Einrichtung erfolgt ist, muss man folgende Befehl in die UserData Sektion eintragen im Cloudformation Template:
UserData: # is executed as root user Fn::Base64: !Sub | #!/bin/bash -xe yum update -y aws-cfn-bootstrap /opt/aws/bin/cfn-init -v --stack ${AWS::StackName} --resource WebServerInstance --configsets InstallAndRun --region ${AWS::Region} /opt/aws/bin/cfn-signal -e $? --stack ${AWS::StackName} --resource WebServerInstance --region ${AWS::Region} reboot
Mit Hilfe der folgende Python AWS Lambda Funktion kann man einen A Record in Route53 erstellen/updaten:
import json import boto3 route53 = boto3.client('route53') def lambda_handler(event, context): print("Received event: " + json.dumps(event, indent=2)) domain = event['domain'] route53.change_resource_record_sets( HostedZoneId='HostedZoneId', ChangeBatch={ 'Comment': 'Update or Insert an A Record', 'Changes': [ { 'Action': 'UPSERT', 'ResourceRecordSet': { 'Name': domain, 'Type': 'A', 'SetIdentifier': domain, 'Region': 'region', 'ResourceRecords': [ { 'Value': '1.1.1.1' } ], 'TTL': 300 } } ] } )
Dazu muss die Labda Funktion die notwendigen Rechte für Route53 besitzen.
Die Dokumentation ist hier.
Die Funktion kann getestet werden mit:
{ "domain": "foo.bar.de" }
Mit dem folgende Befehl kann eine Testmail versendet werden mit Swiftmailer. Falls die Email nicht ankommt, sind die Switftmailer Parameter in config/packages/swiftmailer.yaml wahrscheinlich falsch:
php bin/console swiftmailer:email:send --help
Da die Email mit eine Queue versendet werden, sollte trotzdem in das error_log untersucht werden unter var/log/, darin fand sich bei mir der Grund für mein Versand Problem:
app.ERROR: Exception occurred while flushing email queue: Expected response code 250 but got code "554", with message "554 Message rejected: Email address is not verified. The following identities failed the check in region EU-WEST-1: email1, email2
Um einen mehrzeiligen Text in Cloudformation Templates zu platzieren, gibt es eine elegante Lösung – der YAML >- Operator:
/var/www/html/public/index.php: content: >- <html> <body> <h1>Welcome to the AWS CloudFormation PHP Sample</h1> <p/> <?php // Print out the current data and time print "The Current Date and Time is: <br/>"; print date("g:i A l, F j Y."); ?> <?php phpinfo(); ?> </body> </html>
Alternativ wird in vielen offiziellen Beispielen das sehr unhandliche Format mit der Join Funktion benutzt:
/var/www/html/index.php: content: !Join - '' - - | <html> - |2 <body> - |2 <h1>Welcome to the AWS CloudFormation PHP Sample</h1> - |2 <p/> - |2 <?php - |2 // Print out the current data and time - |2 print "The Current Date and Time is: <br/>"; - |2 print date("g:i A l, F j Y."); - |2 ?> - |2 <?php phpinfo(); ?> - |2 </body> - | </html>
Ich hatte gerade das Problem, dass ich mich nicht mehr mit meinem SSH Key auf meine EC2 Instanz einloggen konnte:
Server refused our key
Ich habe herausgefunden, dass es daran lag, dass ich AWS Opsworks Stacks ausprobiert hatte und genau diesen Key angebeben hatte für den neuen Stack.
Meine Rettung war, dass man sich über die AWS Console auch auf die Instanzen mit SSH verbinden kann ohne das Zertifikat:
Was Opsworks dann getan hat, war die Key von den bestehenden Instanzen zu kopieren und dem root-User, nicht mehr meine ec2-user zuzuteilen.
Dies geschah aber leider auch nicht korrekt, sondern der Key in /root/.ssh/authorized_keys war geändert worden in ein falsches Format durch Opsworks:
command="echo 'Please login as the ec2-user user rather than root user.';echo;sleep 10" xxxxxxxxxxxxxxxxxxxMY SSH Keyxxxxxxxxxxxxxxxxxxx
Um das Login wieder herzustellen, habe ich den Text vor meinem SSH Key entfernt und kopiert nach /home/ec2-user/.ssh/.
Danach müssen noch die passenden Rechte gesetzt werden als ec2-user:
mkdir /home/ec2-user
/.ssh
sudo chown -R ec2-user:ec2-user /home/ec2-user/.ssh
chmod 700 /home/ec2-user
/.ssh
chmod 600 /home/ec2-user
/.ssh/authorized_keys
Danach war das Login wieder möglich. Es sollte nicht vergessen werden, den root SSH Key zu entfernen.
Wenn man den User bei der Eingabe im Browser ohne ein Pfad (www.foo.de) zum Adminbereich von Sonata (www.foo.de/admin) weiterleiten will, kann man dies sehr elegant mittels eines Symfony Redirects in der routing.yml tun:
index: path: / defaults: _controller: FrameworkBundle:Redirect:urlRedirect path: /admin permanent: true