KeyHelp Community

Akecheta wrote: was hintert dich den daran auf 16.04 upzudaten??? kannst dir ja PHP 5.6 selbst kompillieren oder die Sources zumindest installieren...

Und wie schaltet man dann zwischen den verschiedenen Versionen um?

Tobi wrote:Und wie schaltet man dann zwischen den verschiedenen Versionen um?

Im Moment geht das nur durch manuelle Eingriffe in die entsprechenden Konfigurationsfiles mit nachfolgendem Setzen des Immutable-Bits bei den modifizierten Konfigurationsfiles, um sie updateresistent zu machen.

Jolinar wrote:durch manuelle Eingriffe in die entsprechenden Konfigurationsfiles

Wie sieht der manuelle EIngriff genau aus?
Welche Konfigurationsfiles sind gemeint?

Ich verwende Debian 8 / PHP 5.6.irgendwas und würde gerne PHP7 auf ausgewählten, handselektierten Domains testweise mal aufschalten um zu sehen was passiert .

Tobi wrote:Wie sieht der manuelle EIngriff genau aus?
Welche Konfigurationsfiles sind gemeint?

Ich war letztens in der Verlegenheit, PHP 7 unter Debian Jessie zum Laufen bringen zu müssen und habe dabei diese Anleitung als Referenz benutzt.
War zwar in meinem Fall kein Server mit Keyhelp-Setup, sollte aber mit den entsprechenden Anpassungen auch in einem KH-Setup funktionieren.
Kleiner Bonus...Die Anleitung nutzt ein Repo von LiveConfig mit fertig kompilierten PHP-Versionen (5.3, 5.4, 5.5, 5.6, 7.0 und 7.1), man spart sich also das Kompilieren und damit ein bissel Arbeit.

Akecheta wrote:was hintert dich den daran auf 16.04 upzudaten??? kannst dir ja PHP 5.6 selbst kompillieren oder die Sources zumindest installieren...

Ich gehöre zu den Keyweb-Kunden, die einen managed Service haben, um genau so was nicht machen zu müssen, denn dafür reichen die Kenntnisse oder das Vertrauen in einen selbst nicht aus. Es wäre fatal mit einem Server zu experimentieren, auf dem Kundenprojekte liegen.

Es würde Dir eh nichts nutzen solange Du Deinen Kunden keinen simplen "Schalter" zur Verfügung stellen kannst.

Tja, nach dem Changelog der neuen Version 14.8.0 ist diese Funktion leider wieder nicht dabei...

Version 14.8.0 - (very soon) March 2017

New Features
Firewall (Iptables) Management
Added a webmail alternative: Rainloop (optional)
Added "keyhelp/bin/rewrite-user-configs.php" - a script to force rewrite of all user configurations
Launch panel tasks instantly
Store server notes
Enable / disable the tools which come with KeyHelp (webmail / phpmyadmin)
Email accounts can now have alias addresses from a different email domain
Switched (almost all) of the old translation method to gettext
You can specify ScriptAlias for Perl/CGI [required for apache >= 2.4]

Improvements
Backup | Choose between different compression levels (#0000104)
Backup | Now offers multithreading support
Backup | database disaster recovery is now a shell script instead a copy of the whole database
Backup | Mail notification mail now contains a nice user salutation instead of just the username
Apache | Improved cipher list for apache webserver
Apache | Enable mod cgid
Improved layout of domain overview page
Admins receives email if a user changes its contact data
Database | Offer a new tunging.cnf for servers with low memory (only on new install)
Show version number of KeyHelp Tools on admin dashboard
Added ntp daemon to server services management
Added cron daemon to server services management
Internal backup now also contains 'mysql' database
Improved server clock
Improved user info on admin accounts page ( "(?)" )
Added sorting for apache server status page
Various improvements to the template (improved layout; added buttons; streamline list tables; ...)
You can now add a comment / description to your email accounts
Improved TLS PFS settings for the mail system (#0000098)
Improved password generating algorithm for more secure auto generated passwords [backend passwords]
KeyHelp database structure improvements
Improved panel task logs page (added navigation; show latest entries; bigger font-size; ...)
Jump directly to corresponding log file on panel task page
Improved admin dashboard layout
Behavior of input the mailbox quota now is more user friendly
Improved sorting of redirection / alias addresses for user email pages
Code quality improvements / removed unused code / refactoring
Various database query improvements
Added shortcut links for easier log-in into phpmyadmin / webmail on their corresponding user pages (don't work for rainloop)
Moved a big amount of inline styles to the mail style file
If you assign a new directory to a domain, and the directory does not already exist, then the standard index file will be put into the new directory
Roundcube update to 1.2.3
phpseclib update to 1.0.5

Bug fixes / Imperfections
KeyHelp now prevents you from requesting let's encrypt certs for wildcard domains
Fixed "id is ambiguous" if you searched for domains (admin accounts page)
[Ubuntu 16.04] PHP zip extension was missing (#1100229111)
[Ubuntu 16.04] Changed folder structure for mariadb leads to, that tuning.cnf was not loaded in correct order
When sorting the traffic column on admin account page, the sorting icon was missing
Internal API | Could create a user with traffic limit of 0 instead of default unlimited
Internal API | It could happen, that customers with a special account template could not be deleted correctly
Internal API | If users got their password generated by internal API instead normal KeyHelp UI, weak crypt algorithm was used
Fixed wrong event texts (p.ex Russian event texts inside German panel, ...)
KeyHelp news box on admin dashboard was displayed with wrong charset if the file "/etc/php/.../20-charset.ini" was modified - now independent
Fixed some XSS vulnerabilities
Database redirect_codes records for subdomains were not deleted, if the main domain was deleted
Last Roundcube updates could lead to missing address books. This update try to fix this and bring back the address books (#1100228745)
Improved translations (to be more clear, fixed mistakes, spelling)
Fixed a bug with list tables, which cause that to many borders were rendered.
Fixed various PHP errors / warnings / notices
Remove HTML from ajax responses

Jolinar wrote:

Tobi wrote:Wie sieht der manuelle EIngriff genau aus?
Welche Konfigurationsfiles sind gemeint?

Ich war letztens in der Verlegenheit, PHP 7 unter Debian Jessie zum Laufen bringen zu müssen und habe dabei diese Anleitung als Referenz benutzt.
War zwar in meinem Fall kein Server mit Keyhelp-Setup, sollte aber mit den entsprechenden Anpassungen auch in einem KH-Setup funktionieren.
Kleiner Bonus...Die Anleitung nutzt ein Repo von LiveConfig mit fertig kompilierten PHP-Versionen (5.3, 5.4, 5.5, 5.6, 7.0 und 7.1), man spart sich also das Kompilieren und damit ein bissel Arbeit.

Sorry für meine späte Antwort.

Ich habe das alles durchgearbeitet.
Ein großes Fragezeichen bleibt aber.
Inwieweit verträgt eine solch tiefgreifende Änderung am System mit KeyHelp?
Und, was ist wenn Keyhelp das erst einmal selbst kann? Ist dann mein Server noch kompatibel?
Und wie mache ich schlimmstenfalls ein Rollback?

Nein, das kommt dann wohl doch nicht für mein Live System in Frage.
Oder eben erst dann wenn die Devs hier eine Schritt-für-Schritt Anleitung, speziell für Keyhelp Debian 8 veröffentlichen.

Insbesondere war es nämlich der letzte, und auch leider unbeantwortete Kommentar, auf dieser Seite welcher mich von einer Umsetzung abgehalten hat. ==> https://dominicpratt.de/verschiedene-ph ... mment-6115
Das ist nämlich genau meine Ausgangssituation.

Aber trotzdem vielen Dank!
Jetzt kann ich die Lage wenigstens besser einschätzen.

HolgerGr wrote:Tja, nach dem Changelog der neuen Version 14.8.0 ist diese Funktion leider wieder nicht dabei...

Ein sehr grosses LEIDER.

Für mich ist das zur Zeit das absolute Key-Feature welches Keyhelp noch fehlt.

Bei Wordpress lautet nämlich jetzt schon die Installationsempfehlung "PHP version 7 or greater".
==> https://wordpress.org/about/requirements/

Das macht mir ein wenig Sorgen, weil Wordpress doch recht verbreitet ist , ich aber vorerst unmöglich auf PHP 5.6 verzichten kann.

Also bitte liebe Devs, setzt dieses Thema gaaaaaaaaaaaanz weit oben auf die To-Do-Liste.

Danke!

Bei Wordpress lautet nämlich jetzt schon die Installationsempfehlung "PHP version 7 or greater".
==> https://wordpress.org/about/requirements/

Das macht mir ein wenig Sorgen, weil Wordpress doch recht verbreitet ist , ich aber vorerst unmöglich auf PHP 5.6 verzichten kann.

Ich glaube was das angeht, wirst Du Dir noch keine so großen Sorgen machen. Derzeit ist WP sogar noch abwärtskompatibel bis PHP 5.3 wenn ich das richtig sehe. Ein paar wichtige Theme-Anpassungen sind zwischen php 5.4 und 5.5 fällig wenn Themes schlampig geschrieben wurden. Die Core betrifft das aber nicht.

PHP 7 ist noch längst nicht bei allen aktuellen CMS' und Communityscripts umgesetzt. Ein relativ großer Majorplayer, der es noch gar nicht empfiehlt ist Oxwall (Skalfa). Trotzdem wünsche ich mir, dass Keyhelp beim nächsten Update (14.8.1) diese Funktion unterstützt und das nicht weiter aufgeschoben wird.

Tobi wrote:
Ein sehr grosses LEIDER.

Für mich ist das zur Zeit das absolute Key-Feature welches Keyhelp noch fehlt.

Also bitte liebe Devs, setzt dieses Thema gaaaaaaaaaaaanz weit oben auf die To-Do-Liste.

Danke!

Da kann ich mich nur anschließen.

Reseller4711 wrote:

Akecheta wrote:was hintert dich den daran auf 16.04 upzudaten??? kannst dir ja PHP 5.6 selbst kompillieren oder die Sources zumindest installieren...

Ich gehöre zu den Keyweb-Kunden, die einen managed Service haben, um genau so was nicht machen zu müssen, denn dafür reichen die Kenntnisse oder das Vertrauen in einen selbst nicht aus. Es wäre fatal mit einem Server zu experimentieren, auf dem Kundenprojekte liegen.

am Laufendem System sollte man das selbstverständlich nicht "Experimentieren" so wollte ich das nun nicht darstellen, nur muss ich wenn ich mal erlich sein darf, mit dem Server schon umgehen können auch Selbst Kompilieren und Co, klar bringen Managed Server einige vorteile, aber ich bin einer, der lässt niemanden auf sein System drauf... dazu bin ich zu eigen und ggf. Testen kann man das Zuhause in einer Virtuellen Maschiene... aber Backups sind das A und O in diesem falle...

Akecheta wrote: am Laufendem System sollte man das selbstverständlich nicht "Experimentieren" so wollte ich das nun nicht darstellen, nur muss ich wenn ich mal erlich sein darf, mit dem Server schon umgehen können auch Selbst Kompilieren und Co, klar bringen Managed Server einige vorteile, aber ich bin einer, der lässt niemanden auf sein System drauf... dazu bin ich zu eigen und ggf. Testen kann man das Zuhause in einer Virtuellen Maschiene... aber Backups sind das A und O in diesem falle...

Das ist bei mir genau umgekehrt. Ich habe andere Qualitäten, aber Server und SSH sind für mich ein Buch mit 7 Siegeln, auch wenn ich in einem Jahr Keyweb-Kunde viel gelernt habe.
Deshalb nutze ich ja "managed". So habe ich ein paar Freiheiten, muss mich aber um nichts kümmern. Und der Support von Keyweb ist perfekt (jetzt fehlt mir aktueller denn je nur die php Auswahl oder zumindest php 5.6).

Ich weiß .... es kommt, wenn es fertig ist ....
Aber gibt es schon einen ungefähren Zeitplan für "php-Wechsel Methoden"?
Danke

Hallo,

dies wird für das kommende KeyHelp Update das Hauptfeature werden. Aktuell gehen wir von einem Release im Juli aus.

Martin wrote: ↑Thu 15. Jun 2017, 23:20 Hallo,

dies wird für das kommende KeyHelp Update das Hauptfeature werden. Aktuell gehen wir von einem Release im Juli aus.

DANKE