18.06.2025, 08:42
Sprache ändern
Registrieren
Anmelden
Sie sind nicht angemeldet.
- 1
- 2
Shoggy
Sven - Admin
Re: @All-inkl Kunden - einige Fragen
Dienstag, 13. Juli 2004, 22:39
So, ich hab's jetzt nach x Stunden geschafft die wichtigsten Sachen wieder zum Laufen zu bringen. Vor allem die Zugriffsrechte bei den Verzeichnissen haben mich in den Wahnsinn getrieben (ich bin mir auch jetzt noch nicht sicher ob das alles so richtig ist...). Ebenso die Tatsache, dass All-inkl der Meinung ist jede Subdomain mit neuem Webspace auszustatten statt eine feste Weiterleitung zu verwenden.
Ansonsten bin ich zufrieden. Das läuft alles deutlich schneller als Puretec
Ansonsten bin ich zufrieden. Das läuft alles deutlich schneller als Puretec
DerDaniel
God
Re: @All-inkl Kunden - einige Fragen
Mittwoch, 14. Juli 2004, 00:39
Ich habe mir auch schon überlegt, von purtec zu all-inkl zu wechseln, gerade weil ich bei 1und1 in meinen paketen leider kein php, sowie mysql habe... und eine paketerweiterung ist mir eindeutig zu teuer...
wie sieht es denn mit der ausfallsicherheit bzw erreichbarkeit bei bei all-inkl aus?
@ sven
wie genau stell ich den umzug meiner domains an?
sry für den halben topic missbrauch
gruß daniel
wie sieht es denn mit der ausfallsicherheit bzw erreichbarkeit bei bei all-inkl aus?
@ sven
wie genau stell ich den umzug meiner domains an?
sry für den halben topic missbrauch
gruß daniel
RedHead
Senior Member
Re: @All-inkl Kunden - einige Fragen
Mittwoch, 14. Juli 2004, 00:53
Zitat von »Y0Gi«
also moritz und ich sind jetzt schon über ein jahr bei all-inkl und ich schlage regelmäßig die hände über'm kopf zusammen. das geht quer durch den garten.
einzig der preis hält uns noch bei laune.
Warum das denn ? Was ist so schlimm an all-inkl ? Ich bin da auch seit ca einem halben Jahr und soweit zufrieden, liegt vielleicht auch daran, dass meine Ansprüche nicht besonders hoch sind und ich auch keine ernsthafte Seite online hab, daher auch so gut wie keine(n) Zugriffe/Traffic.
-RedHead
DerDaniel
God
Re: @All-inkl Kunden - einige Fragen
Mittwoch, 14. Juli 2004, 00:54
also moritz und ich sind jetzt schon über ein jahr bei all-inkl und ich schlage regelmäßig die hände über'm kopf zusammen. das geht quer durch den garten.
einzig der preis hält uns noch bei laune. aber wer was richtiges will, dem empfehle ich http://www.domainfactory.de oder http://www.hosteurope.de/
@toc: schau mal bei kostenlos.de, da gibts viele angebote mit kostenlosem php+mysql. manchmal gibt es ein paar bedingungen, aber da sollte durchaus was zu finden sein.
das mit den kostenlosen space is alles schön und gut...
habe im moment auch zusätzlich zu meinem normalen webspace, ein bisschen php und mysql space von einem freund..., aber ich will schlussendlich alles unter einem dach haben... und nicht mit meinem und dem externen space rumhantieren müssen...
wenn es um meine private hp gehen würde, wären meine ansprüche sicherlich dem kostenlosen space genüge... jedoch benötige ich ihn für eine vereinshomepage, bei der numal alles einwandfrei und immer laufen muss...
nichtsdestotrotz danke!
achja, bei hosteurope habe ich ein paar reine domains...
ich schau mir mal die hosting konditionen dort an, evtl kann ich ja dorthin wechseln...
Shoggy
Sven - Admin
Re: @All-inkl Kunden - einige Fragen
Mittwoch, 14. Juli 2004, 01:38
Also ich hab das Gefühl, dass ich nicht lange Kunde bei all-inkl sein werde. Mir fehlen hier zig Funktionen, die ich bisher immer als selbstverständlich angesehen habe.
Am schlimmsten finde ich das Domain-Handling. Die behandeln jede (Sub-)Domain entweder wie ein völlig neues Paket oder man trägt sie als CNAME ein und hat wiederum gar keine Funktionen ausser das sie da ist ;D
Mein Workaround wäre im moment folgender: ich stelle für die restlichen Domains ein eigenes Paket ein und nehme nur 1MB, was wohl das kleinstmögliche ist. Da schmeiss ich dann eine .htaccess mit dem Inhalt
RewriteEngine On
RewriteRule ^(.*)$ http://www.shoggy.de/$1[url][/url]
rein damit man unter www.shoggy.com/bla/blub.jpg das gleiche sieht wie unter www.shoggy.de/bla/blub.jpg.
Sieht nicht schön aus weils im Browser auch wieder geändert wird (evtl. nur Einstellungssache der .htaccess) und frisst zudem Performance.
Der Lohn: so kann ich wenigstens unter allen 4 Domains nach Lust und Laune eMails einrichten.
Und ansonsten kann ich es mir nicht verkneifen erneut über das Kundenmenü zu meckern ;D Das sieht nicht nur aus als hätte es ein Schüler für 'ne Tüte Gummibärchen programmiert sondern genau so wird's wohl auch sein
Nicht mal die "Hilfe"-Texte darin bringen einen weiter. Auch die Anleitungen auf der Hauptseite verwirren mehr statt einem die Funktion verständlich zu machen.
@Y0Gi:
Was kann einen denn da noch so erwarten? Scheints ja auch nicht gerade begeistert zu sein
Am schlimmsten finde ich das Domain-Handling. Die behandeln jede (Sub-)Domain entweder wie ein völlig neues Paket oder man trägt sie als CNAME ein und hat wiederum gar keine Funktionen ausser das sie da ist ;D
Mein Workaround wäre im moment folgender: ich stelle für die restlichen Domains ein eigenes Paket ein und nehme nur 1MB, was wohl das kleinstmögliche ist. Da schmeiss ich dann eine .htaccess mit dem Inhalt
RewriteEngine On
RewriteRule ^(.*)$ http://www.shoggy.de/$1[url][/url]
rein damit man unter www.shoggy.com/bla/blub.jpg das gleiche sieht wie unter www.shoggy.de/bla/blub.jpg.
Sieht nicht schön aus weils im Browser auch wieder geändert wird (evtl. nur Einstellungssache der .htaccess) und frisst zudem Performance.
Der Lohn: so kann ich wenigstens unter allen 4 Domains nach Lust und Laune eMails einrichten.
Und ansonsten kann ich es mir nicht verkneifen erneut über das Kundenmenü zu meckern ;D Das sieht nicht nur aus als hätte es ein Schüler für 'ne Tüte Gummibärchen programmiert sondern genau so wird's wohl auch sein
Nicht mal die "Hilfe"-Texte darin bringen einen weiter. Auch die Anleitungen auf der Hauptseite verwirren mehr statt einem die Funktion verständlich zu machen.
@Y0Gi:
Was kann einen denn da noch so erwarten? Scheints ja auch nicht gerade begeistert zu sein
Y0Gi
God
Re: @All-inkl Kunden - einige Fragen
Mittwoch, 14. Juli 2004, 03:58
für all-inkl haben wir sogar nen eigenen forumsthread
ich fasse mal einige dinge zusammen:
- es kommt immer wieder (nicht oft, aber doch merklich oft) zu extrem schlechter oder auch gar keiner erreichbarkeit
- das KAS ist ne katastrophe in der benutzerführung
- das handling der subdomains ist nicht unbedingt vorteilhaft (ich find es scheisse)
- beim anlegen von autorespondern, mailfiltern u.a. wird im root für jede einrichtung ne eigene datei angelegt, die dann zwischen den eigentlichen html-dateien rumfliegt. zusammen mit cgi-bin, logfiles, etc. mehr dazu siehe weiter unten
- die einrichtung von subdomains und ftp-accounts dauert meist recht lange zur aktivierung
- benutzernamen sind teilweise vorgegeben, unterliegen gewissen unnötigen beschränkungen (in der länge, nur buchstaben, eine zahl, ... weiß nimmer, ganz komisch - hat aber trotzdem fast nix von funktioniert) und sind offenbar server-weit einmalig, d.h. wenn wer anders nen user "peter" anlegt, kann man das selbst nicht mehr
- die passwörter dürfen nur lächerlich kurz sein
- entgegen der auf http://info.dd1816.kasserver.com/ beworbenen php-version fehlt bei uns einiges und der safe-mode ist aus (wollte unlängst mal ne mail schreiben)
- entgegen deren aussage funktioniert url-rewriting nicht im root, nur in subverzeichnissen. damit kann man z.b. kein aus obigen genannten gründen sinnvolles "moved document root" einrichten; sowas sollte eigentlich standard sein
- irgendeine datenbank mit sensitiven daten (damit konnte ich mich auf einigen seiten in die internen bereiche einloggen...) wurde komplett für alle all-inkl-user als "test"-db in phpmyadmin sichtbar. auf unsere nachfrage was das wohl soll, hat man die dann entfernt. toller test.
- man kann weder per ftp- noch auf mail-accounts ssl-verschlüsselt zugreifen
- beim anmelden einer zweiten domain haben wir als benutzernamen 'oldmt' bekommen - wie der wohl beim anmelden einer dritten domain aussieht? das ganze ist dann präfix für diverse andere zugangsdaten. als passwort wurde nur eine marginal unterschiedliche, aber ungleich unsichere zeichenkette gewählt. insgesamt hab ich den eindruck, die haben da nen praktikanten sitzen, der das verzapft.
ich werde nach meinen klausuren äußern, dass ich gerne zumindest die zweite domain mit einem aktuellen, sicheren und mit aktuellen features (xslt, openssl, gdlib mit png statt gif, ...) kompilierten php sowie komplett funktionalem url-rewriting sehen möchte, ansonsten steht ein wechsel an. das scheint mir alles zu sehr hingeklatscht und lari-fari zu sein. wenig funktioniert, wie man es erwartet. damit kann man auf lange sicht einfach nicht ordentlich arbeiten, wenn man mehr als nur ein bisschen php und mysql will - und das gibts schon an jeder ecke.
nach meinen heutigen erkundungen ist domainfactory (habe sehr gute erfahrung beim hosting mehrer domains dort) für unsere zwecke zu teuer, aber host europe hätte da direkt ne anmeldung im briefkasten: imap-postfächer, pop3, imap und ftp per ssl, neben php und perl geht dort auch python, ruby und tcl, mysql 4, uvm.
@toc:
naja ein verein ist ja nicht unbedingt ne kommerzielle sache, aber wenn die das gerne orderntlich haben und bezahlen möchten, dann findet sich da sicherlich was.
@shoggy:
du meintest "wird im browser wieder geändert". wenn man [PT] als dritte spalte an die rewriterule anhängt, sollte das bestehen bleiben.
bei uns leite ich alte artikel-urls weiter, aber die /artikel/id/seite/-urls sind selbst nur ein passthrough auf die neuen urls (die wiederum mit parametern funktionieren). da das wahrscheinlich nicht so ganz rüberkommt, hier mal die .htaccess:
aber was mich dabei wirklich ankotzt (vgl. oben) ist die tatsache, dass ich diese datei in /articles/ ablegen muss, im / klappt es (nach den entsprechenden änderungen natürlich) partout nicht! *aufreg* und das ist sicher kein fehler meinerseits...
ich fasse mal einige dinge zusammen:
- es kommt immer wieder (nicht oft, aber doch merklich oft) zu extrem schlechter oder auch gar keiner erreichbarkeit
- das KAS ist ne katastrophe in der benutzerführung
- das handling der subdomains ist nicht unbedingt vorteilhaft (ich find es scheisse)
- beim anlegen von autorespondern, mailfiltern u.a. wird im root für jede einrichtung ne eigene datei angelegt, die dann zwischen den eigentlichen html-dateien rumfliegt. zusammen mit cgi-bin, logfiles, etc. mehr dazu siehe weiter unten
- die einrichtung von subdomains und ftp-accounts dauert meist recht lange zur aktivierung
- benutzernamen sind teilweise vorgegeben, unterliegen gewissen unnötigen beschränkungen (in der länge, nur buchstaben, eine zahl, ... weiß nimmer, ganz komisch - hat aber trotzdem fast nix von funktioniert) und sind offenbar server-weit einmalig, d.h. wenn wer anders nen user "peter" anlegt, kann man das selbst nicht mehr
- die passwörter dürfen nur lächerlich kurz sein
- entgegen der auf http://info.dd1816.kasserver.com/ beworbenen php-version fehlt bei uns einiges und der safe-mode ist aus (wollte unlängst mal ne mail schreiben)
- entgegen deren aussage funktioniert url-rewriting nicht im root, nur in subverzeichnissen. damit kann man z.b. kein aus obigen genannten gründen sinnvolles "moved document root" einrichten; sowas sollte eigentlich standard sein
- irgendeine datenbank mit sensitiven daten (damit konnte ich mich auf einigen seiten in die internen bereiche einloggen...) wurde komplett für alle all-inkl-user als "test"-db in phpmyadmin sichtbar. auf unsere nachfrage was das wohl soll, hat man die dann entfernt. toller test.
- man kann weder per ftp- noch auf mail-accounts ssl-verschlüsselt zugreifen
- beim anmelden einer zweiten domain haben wir als benutzernamen 'oldmt' bekommen - wie der wohl beim anmelden einer dritten domain aussieht? das ganze ist dann präfix für diverse andere zugangsdaten. als passwort wurde nur eine marginal unterschiedliche, aber ungleich unsichere zeichenkette gewählt. insgesamt hab ich den eindruck, die haben da nen praktikanten sitzen, der das verzapft.
ich werde nach meinen klausuren äußern, dass ich gerne zumindest die zweite domain mit einem aktuellen, sicheren und mit aktuellen features (xslt, openssl, gdlib mit png statt gif, ...) kompilierten php sowie komplett funktionalem url-rewriting sehen möchte, ansonsten steht ein wechsel an. das scheint mir alles zu sehr hingeklatscht und lari-fari zu sein. wenig funktioniert, wie man es erwartet. damit kann man auf lange sicht einfach nicht ordentlich arbeiten, wenn man mehr als nur ein bisschen php und mysql will - und das gibts schon an jeder ecke.
nach meinen heutigen erkundungen ist domainfactory (habe sehr gute erfahrung beim hosting mehrer domains dort) für unsere zwecke zu teuer, aber host europe hätte da direkt ne anmeldung im briefkasten: imap-postfächer, pop3, imap und ftp per ssl, neben php und perl geht dort auch python, ruby und tcl, mysql 4, uvm.
@toc:
naja ein verein ist ja nicht unbedingt ne kommerzielle sache, aber wenn die das gerne orderntlich haben und bezahlen möchten, dann findet sich da sicherlich was.
@shoggy:
du meintest "wird im browser wieder geändert". wenn man [PT] als dritte spalte an die rewriterule anhängt, sollte das bestehen bleiben.
bei uns leite ich alte artikel-urls weiter, aber die /artikel/id/seite/-urls sind selbst nur ein passthrough auf die neuen urls (die wiederum mit parametern funktionieren). da das wahrscheinlich nicht so ganz rüberkommt, hier mal die .htaccess:
|
Quellcode |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
# $Id: .htaccess,v 1.4 2004/06/24 23:37:36 yogi Exp $
RewriteEngine On
Options +FollowSymLinks
# new article urls matching /articles/<ArticleID>/(PageID)/
RewriteRule ^([0-9]+)/(([0-9]+)/)?$ /article.php?id=$1&page=$3 [PT,L]
# print article /articles/<ArticleID>/print/
RewriteRule ^([0-9]+)/print/$ /printarticle.php?id=$1 [PT,L]
# old article urls matching /articles/?id=<ArticleID>
RewriteCond %{QUERY_STRING} ^id=([0-9]+)$
RewriteRule ^$ /articles/%1/? [R,L]
# sections - /articles/sections/<Section>/
RewriteRule ^sections/(.+)/$ /article.php?show=list§ion=$1 [PT,L]
# stats - /articles/stats/
RewriteRule ^stats/$ /article.php?show=stats [PT,L]
|
aber was mich dabei wirklich ankotzt (vgl. oben) ist die tatsache, dass ich diese datei in /articles/ ablegen muss, im / klappt es (nach den entsprechenden änderungen natürlich) partout nicht! *aufreg* und das ist sicher kein fehler meinerseits...
- 1
- 2