- Entwicklung - example.com

xRes external update
by Oliver Horn 14 Dec '17

14 Dec '17

Moin, es ist mal wieder soweit das es ein external Update gibt. Welche dummen Änderungen gibt es nun schon wieder? jQuery 3.2.1 geadded jQueryUI 1.12.1 geadded jQUery 2.2.3 entfernt jQueryUI 1.11.4 entfernt jQuery migration 1.4 entfernt Datepicker entfernt (da haben wir schon die 5.0.1) Was muss ich machen damit mein xAdmin funktioniert? 1. Von der Theorie muss nur das xres-setup script aufgerufen werden, sprich "php composer.phar xres-setup". 2. Ich schätze jedoch das viele das ExternalRepo + das BuildCustomerRepo noch nicht auf das Gitlab umgestellt haben und manche von euch ein Permission Fehler bekommen werden. Deswegen dann einfach den Remote auf das Gitlab setzen externals => git@git.app.infra.gs.xtrav.de:xRes/externals.git build_customer_config => git@git.app.infra.gs.xtrav.de:xRes/build_customer_config.git 3. Solltet ihr einen Permission Fehler bekommen aber schon den richtigen Remote hinterlegt haben dann, bitte in den build_customer_config bzw in externals gehen und dann "git pull origin master" aufrufen. PS Nach Step 2 und 3 einfach nochmal "php composer.phar xres-setup aufrufen" -- Mit freundlichen Grüßen Oliver Horn - Entwicklung - ________________________________________________________ TraSo GmbH Nonnenstraße 42 D-04229 Leipzig Tel.: +49 341 90 987 45 E-Mail: o.horn(a)traso.de Internet: http://www.traso.de ________________________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig, HRB 21850

1 0

data01.4ybk
by Thomas Koelzow 11 Dec '17

11 Dec '17

Hi, wie besprochen haben wir einen Data01 mit Centos bereitgestellt auf denen die ersten "live tests" gemacht werden könnten. der Server ist der Data von 4ybk data01.4ybk.xres.rz1.xtrav.de das Import/Export Verzeichnis vom aktuellen Data01.rz1.4ybk.xres.de ist auf den Server gemountet, womit man sofort live arbeiten kann. Default PHP ist 7.1 Bei Fragen, Fragen. -- Mit freundlichen Grüßen Thomas Kölzow - Systemadministration - _______________________________________________ TraSo GmbH Nonnenstraße 42 D-04229 Leipzig E-Mail: t.koelzow(a)traso.de Internet: https://www.traso.de _______________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig (HRB 21850)

1 0

PHP Update xRes
by Oliver Horn 06 Dec '17

06 Dec '17

Mahlzeit, es gibt nun eine kleine Anleitung für die PHP7.1 Installation im Wiki unter https://wiki.app.infra.gs.xtrav.de/doku.php?id=root:traso:entwicklung:php_u… Wenn Ihr von PHP 5.6 auf 7.1 updaten wollt für die Unittests müsst ihr nur davor die alte PHP Version removen, das geht am einfachsten via yum remove php56w php56w-opcache php56w-cli php56w-common php56w-gd php56w-intl php56w-mbstring php56w-mcrypt php56w-mysql php56w-pdo php56w-pear php56w-soap php56w-xml php56w-xmlrpc dannach einfach die PHP7.1 installation starten via yum install mod_php71w php71w-opcache php71w-cli php71w-common php71w-gd php71w-intl php71w-mbstring php71w-mcrypt php71w-mysql php71w-pdo php71w-pear php71w-soap php71w-xml php71w-xmlrpc php71w-pecl-xdebug php71w-pecl-mongodb ggf. müsst ihr dannach noch einmal eure php Einstellung prüfen bzglich des Charsets und der Zeitzone, wie auch im Wiki geschrieben. Somit laufen dann eure tests mit PHP71 auf eurer Kiste und auf dem Bamboo mit PHP54, es ist jedoch auch möglich weiter hin mit PHP56 auf eurer Kiste zuarbeiten, da die tests auch im Container bzw auf der VM gestartet werden könnten. Zusätzlich habe ich heute noch einmal den Docker Container für PHP71 geupdated mit der mongodb Abhängigkeit. Somit laufen dann 2 Container bei euch der "xres" Container ist mit PHP56 (Port 8080) und der "xres71" ist mit PHP71 (Port 8085). -- Mit freundlichen Grüßen Oliver Horn - Entwicklung - ________________________________________________________ TraSo GmbH Nonnenstraße 42 D-04229 Leipzig Tel.: +49 341 90 987 45 E-Mail: o.horn(a)traso.de Internet: http://www.traso.de ________________________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig, HRB 21850

1 0

Apache MPM, PHP & OpCache Rant/Dinge
by Felix Seidel 24 Nov '17

24 Nov '17

Moin, wie einige mitbekommen haben ist heute/gestern der Apache freigedreht. Grund dafür war, dass ich im Zuge diverser Performance-Optimierungen auf unserem Testserver (der noch auf Debian läuft) den MPM-Mode vom Apache auf Worker gestellt hatte. Nebenbei hatte ich das Konstrukt noch auf PHP-FPM gedreht, hatte mich aber vorerst dagegen entschieden das auch direkt auf den Live-Maschinen einzusetzen. Getestet, soweit wie nötig gehalten, läuft. Denkste. Heute nach dem Deployment sind uns regelrecht alle CPU-Kerne um die Ohren geflogen, meisten Load von 30, Spitzen von 60, bei 12 Kernen. Zurückstellen könnte ich nicht, da wir nicht ausschließen können das gerade Buchalterische Sachen laufen und weil sich da niemand rantraut konnte ich erst jetzt wieder eingreifen. Was auch gut so ist. Nach ewigen herumgetüftel auf unsere Devsystem, welches auf CentOS läuft (PHP-Paket von Webtactic), bin ich auf der Suche nach der OpCache config darüber gestolpert, dass die PHP-Installationen gar kein Opcache Paket haben -.- . Japp, so hab ich auch geguckt. Also OpCache drauf, Speicher, String-Länge und Max-Datei-Anzahl (Default 4000, wir liegen mit vendor aber bei ~15k) hochgesetzt, et voila, brauchbare Antwortzeiten (Login-Seite, vorher 700ms, danach 280ms). Statt die Konfig nur zurückzudrehen, konnte ich also doch noch was brauchbares aus der Aktion ziehen. Warum genau nun Prefork besser ohne Opcache umgehen kann als MPM-Worker oder Event ist mir nicht ganz klar, aber das brachte mich zum nächsten Thema. Wenn die Kisten einmal eingerichtet sind und niemand darauf arbeitet (tatsächlich gar keine Requests) hab ich gleich noch nach Untersucht, wie sie die Verschiedenen Modi unter Last verhalten. Leider ist meine Leitung etwas begrent, aber ab hilft da weiter. AB - Apache Benchmark getestet wurden Worker, Event und Prefork (in der Reihenfolge): Worker: ➜ ~ ab -c 1000 -n 5000 -C "PHPSESSID=ong0fut5892mgr38afqttthu47" https://www.xmid.de/main/booking/get-partial-service-details/sId/\?bId\=117… This is ApacheBench, Version 2.3 <$Revision: 1430300 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking www.xmid.de (be patient) Completed 500 requests Completed 1000 requests Completed 1500 requests Completed 2000 requests Completed 2500 requests Completed 3000 requests Completed 3500 requests Completed 4000 requests Completed 4500 requests Completed 5000 requests Finished 5000 requests Server Software: Apache/2.4.6 Server Hostname: www.xmid.de Server Port: 443 SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,4096,128 Document Path: /main/booking/get-partial-service-details/sId/?bId=11705 Document Length: 0 bytes Concurrency Level: 1000 Time taken for tests: 116.750 seconds Complete requests: 5000 Failed requests: 55 (Connect: 0, Receive: 0, Length: 55, Exceptions: 0) Write errors: 0 Non-2xx responses: 77 Total transferred: 2581822 bytes HTML transferred: 12939 bytes Requests per second: 42.83 [#/sec] (mean) Time per request: 23350.090 [ms] (mean) Time per request: 23.350 [ms] (mean, across all concurrent requests) Transfer rate: 21.60 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 8879 11709.4 5515 81112 Processing: 331 11756 3240.6 11938 30144 Waiting: 0 11749 3358.0 11918 42206 Total: 490 20635 12612.5 18063 93474 Percentage of the requests served within a certain time (ms) 50% 18063 66% 19944 75% 21118 80% 21745 90% 28019 95% 47475 98% 84531 99% 84762 100% 93474 (longest request) ============== Event: ➜ ~ ab -c 1000 -n 5000 -C "PHPSESSID=ong0fut5892mgr38afqttthu47" https://www.xmid.de/main/booking/get-partial-service-details/sId/\?bId\=117… This is ApacheBench, Version 2.3 <$Revision: 1430300 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking www.xmid.de (be patient) Completed 500 requests Completed 1000 requests Completed 1500 requests Completed 2000 requests Completed 2500 requests Completed 3000 requests Completed 3500 requests Completed 4000 requests Completed 4500 requests Completed 5000 requests Finished 5000 requests Server Software: Apache/2.4.6 Server Hostname: www.xmid.de Server Port: 443 SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,4096,128 Document Path: /main/booking/get-partial-service-details/sId/?bId=11705 Document Length: 0 bytes Concurrency Level: 1000 Time taken for tests: 117.501 seconds Complete requests: 5000 Failed requests: 167 (Connect: 0, Receive: 0, Length: 167, Exceptions: 0) Write errors: 0 Non-2xx responses: 332 Total transferred: 2523071 bytes HTML transferred: 17872 bytes Requests per second: 42.55 [#/sec] (mean) Time per request: 23500.233 [ms] (mean) Time per request: 23.500 [ms] (mean, across all concurrent requests) Transfer rate: 20.97 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 7972 8189.7 5559 86900 Processing: 313 12832 2812.0 13140 31232 Waiting: 270 12818 2823.8 13132 34819 Total: 482 20804 8694.4 18921 98796 Percentage of the requests served within a certain time (ms) 50% 18921 66% 20231 75% 21485 80% 22528 90% 27933 95% 33931 98% 51330 99% 56858 100% 98796 (longest request) ============== Prefork: ➜ ~ ab -c 1000 -n 5000 -C "PHPSESSID=ong0fut5892mgr38afqttthu47" https://www.xmid.de/main/booking/get-partial-service-details/sId/\?bId\=117… This is ApacheBench, Version 2.3 <$Revision: 1430300 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking www.xmid.de (be patient) Completed 500 requests Completed 1000 requests Completed 1500 requests Completed 2000 requests Completed 2500 requests Completed 3000 requests Completed 3500 requests Completed 4000 requests Completed 4500 requests Completed 5000 requests Finished 5000 requests Server Software: Apache/2.4.6 Server Hostname: www.xmid.de Server Port: 443 SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,4096,128 Document Path: /main/booking/get-partial-service-details/sId/?bId=11705 Document Length: 0 bytes Concurrency Level: 1000 Time taken for tests: 110.483 seconds Complete requests: 5000 Failed requests: 0 Write errors: 0 Total transferred: 2575000 bytes HTML transferred: 0 bytes Requests per second: 45.26 [#/sec] (mean) Time per request: 22096.514 [ms] (mean) Time per request: 22.097 [ms] (mean, across all concurrent requests) Transfer rate: 22.76 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 157 7907 11700.4 4872 90004 Processing: 272 12096 3321.8 11865 33737 Waiting: 224 12075 3306.7 11861 33736 Total: 429 20003 12315.3 17096 105157 Percentage of the requests served within a certain time (ms) 50% 17096 66% 18746 75% 20690 80% 22374 90% 26816 95% 34028 98% 78218 99% 83130 100% 105157 (longest request) Testbedingung: immer die selbe Maschine (der HA Balanced nach Herkunft, der alte Rassist...), immer 5000 Requests und es wird mit einer concurrency von 1000 gearbeitet. Ich nehm an, er versucht 1000 Anfragen gleichzeitig rauszuhämmern, was ich bei meiner Leitung für eher unwahrscheinlich halte, egal. Interressant ist: Gesamtzeiten: 116 | 117 | 110s Der Punkt geht an den Prefork, wobei der auch den ingesamt langsamsten Request mit 105s dabei hatte. Wenn ich mir das genau ansehe sprechen alle Werte für den Prefork. Nichtsdestotrotz zeigt der Test die CPU auslastung nicht. Die lagen nämlich bei max 50 | 30 | 15, was wieder für den Prefork spricht. Und der Prefork war auch der einzige der keine Requests gedroppt hat. Im Endeffekt bin ich gespannt wie die Last morgen auf den Kisten aussieht, ich hab wieder den Prefork als MPM-Mittel der wahl gesetzt. Sicherlich könnte man jetzt noch an der Menge der maximalen Requests, Server, Childs ect herumdoktorn, aber dafür gibts ja das nächste Release ;) Bei Fragen immer her damit! VG Felix -- Mit freundlichen Grüßen Felix Seidel - Entwicklung - ________________________________________________________ TraSo GmbH Nonnenstraße 42 D-04229 Leipzig Tel: +49 341 355 740 47 E-Mail: f.seidel(a)traso.de Internet: https://www.traso.de ________________________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig, HRB 21850

1 0

Code PHP Setter Method template - discussion
by Dragan Mladjenovic 28 Sep '17

28 Sep '17

Hi everybody. I was looking at the wiki page about the code templates https://wiki.app.infra.gs.xtrav.de/doku.php?id=root:traso:entwicklung:codes… I have noticed that the code for *Code PHP Setter Method* has a little change in comparison to the original template in the PHPstorm |/**| |||* @param ${TYPE_HINT} $${PARAM_NAME}| |#if (${STATIC} != "static")| |||* @return self| |#end| |||*/| |public| |${STATIC} ||function| |set${NAME}($${PARAM_NAME})| |{| |#||if| |(${STATIC} == ||"static"||)| |||self::$${FIELD_NAME} = $${PARAM_NAME};| |#||else| |||$this||->${FIELD_NAME} = $${PARAM_NAME};| |||return| |$this||;| |#||end| |}| If you are returning $this, it is called FLUENT setter....so that you can chain setters on the object. This is already a part of the previous template in the wiki page|| || *| |**Code PHP Fluent Setter Method* |/**| |||* @param ${TYPE_HINT} $${PARAM_NAME}| |||* @return self| |||*/| |public| |function| |set${NAME}($${PARAM_NAME})| |{| |||$this||->${FIELD_NAME} = $${PARAM_NAME};| |||return| |$this||;| |} |So In my opinion, no need to return $this from a method which is not made with a FLUENT template. In the screenshot below, we see that we have an option to choose fluent or normal setter. Greetings, Dragan

1 1

GitLab File Tree
by Viktoras Bezaras 26 Sep '17

26 Sep '17

Hallo zusammen, wer Datei-Baum vom Stash vermisst kann gern Browser-Plugin (https://github.com/tomasbonco/gitlabtree) installieren. So schön vom Aussicht ist es nicht, find ich trotzdem viel einfacher die PRs damit zu prüfen. Es gibt auch andere Plugins, die bei mir nicht funktioniert haben. Kann an der neue GitLab Version liegen, und wenn diese aktualisiert werden, werden sie dann besser. VG Viktoras -- Mit freundlichen Grüßen Viktoras Bezaras - Entwickler - ________________________________________________________ TraSo GmbH Nonnenstraße 42 D-04229 Leipzig Tel.: +49 341 355 740 44 E-Mail: v.bezaras(a)traso.de Internet: http://www.traso.de ________________________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig, HRB 21850

1 0

Umzug xRes auf GitLab
by Stefan Rank-Kunitz 22 Sep '17

22 Sep '17

Moin, xRes ... und ALLES andere, was wir im Stash hatten und weiterhin haben wollen ... ist jetzt ins GitLab umgezogen. Stash ist tot, Friede seiner Asche. 1. Bitte prüft, ob alle Repos, die TraSo weiterhin benötigt, im GitLab sind. Was weg ist ... ist weg! 2. Bitte prüft, ob alle Änderungen, die ihr gemacht habt, im GitLab-Repo drin sind. Ich weiß schon, dass der develop nicht aktuell war, das update ich Montag. 3. Lokal müsst ihr NUR die URL Eures origin neu setzen (in jedem geklonten Repo), dann könnt ihr wieder arbeiten. git remote set-url origin <newurl> Dabei ist <newurl> der Wert, den ihr im GitLab auf der Projektseite oben in der Mitte kopieren könnt, z.B. git@git.app.infra.gs.xtrav.de:xRes/xres.git (ein ssh:// davor ist nicht erforderlich). 4. Das Thema Rechte im GitLab löse ich ebenfalls Montag. Ziel ist es, dass alle Entwickler in alle erforderlichen Branches mergen/pushen können ... aber nur dort auch in den "master", wo wir fast nur mit dem master arbeiten (z.B build_customer_config oder flightcheck oder ...). Ich habe im Bamboo alle Build-Prozesse angepasst, es wird NUR NOCH aus dem Gitlab gezogen. Leider bockt Bamboo erheblich dabei, seinen Repo-Cache zu vergessen. Außerdem stehen in Composer-Konfigurationen noch Verweise auf Stash drin, auch das bauen OHO und ich Montag schnell um ... dann wird xRes wieder gebaut. Sport frei! VG SRK -- Mit freundlichen Grüßen Stefan Rank-Kunitz - Lead Developer - ________________________________________________________ TraSo GmbH Nonnenstraße 42 D-04229 Leipzig Tel.: +49 341 355 740 - 43 E-Mail: s.rank-kunitz(a)traso.de ________________________________________________________ Handelsregister: Amtsgericht Leipzig, HRB 21850

1 0

xres logrotate
by Soeren Pestner 20 Sep '17

20 Sep '17

Mit unseren Kunden AWT und ASM haben wir das erste mal den Fall das sich beide Kunden einen service Rechner teilen und damit gibt es kleinere Probleme mit dem deployment. Einiges konnten wir schon lösen, danke SRK. Aktuell müssen wir uns Gedanken zum logrotate deployment machen. 1. Aktuell werden logrotates über das config deployment ausgerollt. Diese werden unter /var/xres/kunde/config/etc/logrotate.d/ abgelegt. Per chef und ansible ist aber der Pfad /var/xres/etc/logrotate.d/ inkludiert. Das ist mal so gewesen, bevor wir Kunden-spezifische configs ausrollten und muss angepasst werden. 2. Alle ausgerollten logrotates mache das gleiche, sie beachten also nicht die kundenspezifischen log Verzeichnisse. Sie würden sich also gegenseitig die Dateien weg nehmen. 3. Was soll wie rotiert werden. Bisherige mir bekannte log Verzeichnisse: /var/www/xres_kunde/*/log/ /var/log/xres/hotel-import (wird noch kundenspezifisch gemacht) /var/log/xres/kunde/* 3.a Eine Aussage ist, dass sich die Entwickler selbst um ihre logs kümmern sollen also auch für die richtigen logrotates verantwortlich sind. 3.b Eine andere Aussage hinterfragt die Sinnhaftigkeit der modul- und kundenspezifischen Behandlung der logs. Logs sind logs also warum unterschiedlich behandeln. 3.c Wir haben z.B. mit den xadmin debug logs tatsächlich logs, die speziell rotiert werden, dafür gibt es ein extra script. Idee: ----- 1. Wir verwenden /var/xres/kunde/* als Standard log Verzeichnis. Alles was da hin geht, wird ohne eigenes Zutun wie gewöhnliche logs behandelt. Das logrotate würde über chef bzw. ansible ausgerollt. Scheinbar ist es aber nicht möglich ein Verzeichnis rekursiv abzuarbeiten. Wir müssten uns also auf eine Ordner Struktur einigen, in der alle logs in der selben Ebene liegen. 2. Die logs unter /var/www/xres_kunde/*/log ist Entwicklersache. Diese logs unterliegen alleinig der Obhut des Entwicklers und müssen ggf. über extra logrotates, die deployed werden können, behandelt. 3. Das logrotate deployment wird überarbeitet und bietet dann die Möglichkeit kunden- bzw. modulspezifische Einstellungen vorzunehmen aber eben nur für die /var/www/xres_kunde/*/log -- -- Sören Pestner - Entwickler - TraSo GmbH Nonnenstraße 42 D-04229 Leipzig telefon: +49 341 909 87 49 email: s.pestner(a)traso.de Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig (HRB 21850)

1 0

TraSo Code Style Extension
by Viktoras Bezaras 08 Sep '17

08 Sep '17

Hello everyone, we agreed some time ago, that we would use PSR-2 code style for xRes development. http://confluence.app.infra.gs.xtrav.de/display/Entwicklung/Codestyles PSR-2 however is a very general recommendation. Many things we do intuitively, I believe it's time to extend a little bit a list of our rules, to make them more clear. My proposal is to partially adopt Symfony Framework Coding Stadard, since it shares a lot of rules with what we already do. https://symfony.com/doc/3.3/contributing/code/standards.html Specifically: - Follow the standards defined in the PSR-0, PSR-1, PSR-2 and PSR-4 documents. - Add a single space after each comma delimiter (E.g. func($a, $b, $c); or [$a, $b, $c]) - Add a single space around binary operators (==, &&, ...). I suggest always use spaces around concatenation as well. (E.g. $a . $b, $a == $b) - Place unary operators (!, --, ...) adjacent to the affected variable (E.g. !$a, not ! $a) - Use braces to indicate control structure body regardless of the number of statements it contains; (E.g. if ($a) { doThis(); }) - Declare class properties before methods; - Use parentheses when instantiating classes regardless of the number of arguments the constructor has; (E.g. new Obj(); not new Obj;) - Do not use spaces around [ offset accessor and before ] offset accessor. (E.g. $a[$b[1]], not $a[ $b[1] ]) - Use camelCase, not underscores, for variable, function and method names, arguments; - Prefix abstract classes with Abstract - Suffix interfaces with Interface - Suffix traits with Trait - Suffix exceptions with Exception - Use alphanumeric characters and underscores for file names (Letters and numbers, no special characters) - For type-hinting in PHPDocs and casting, use bool (instead of boolean or Boolean), int (instead of integer), float (instead of double or real); - Omit the @return tag if the method does not return anything; - The @package and @subpackage annotations are not used. These are just, what I believe we can easily agree on without much discussion. There are more rules in the Symfony document. If you feel some other should also be included - please let everyone know. Best regards Viktoras Bezaras -- Mit freundlichen Grüßen Viktoras Bezaras - Entwickler - ________________________________________________________ TraSo GmbH Nonnenstraße 42 D-04229 Leipzig Tel.: +49 341 355 740 44 E-Mail: v.bezaras(a)traso.de Internet: http://www.traso.de ________________________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig, HRB 21850

3 6

Wiki - Docker
by Denny Brandes 11 Aug '17

11 Aug '17

Hallo zusammen, ich habe den Vortrag über Docker vom Dienstag in unser Wiki gelegt. https://wiki.app.infra.gs.xtrav.de/doku.php?id=root:traso:entwicklung:docker -- Mit freundlichen Grüßen Denny Brandes - Entwicklung ________________________________________________________ TraSo GmbH Nonnenstraße 42 D-04229 Leipzig Tel: +49 341 355 740 55 E-Mail: [d.brandes](a)traso.de Internet: https://www.traso.de ________________________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig, HRB 21850

1 0