Hallo Freunde,

habe eine frage, sobald ich unter ispcp einen webpacket erstelle muß ich einen domain eingeben und dieser domain ist auch das loginname von dem webpacket.

wenn ich aber unter den Webpacket einen ftp zugang anlege und datenbank anlege muß ich neue benutzername erstellen.

warum wird den das Domain nicht automatisch auch bei ftp und mysqluser automatisch erstellt so das ich mit einem Benutzernamen auf alle bereiche einlogge.

Weil momentan kann ich auf dem Acount belibige username für ftp und mysql erstellen.

Nachteil an dieser methode ist das man irgendwie keinen überblick bekommt wenn es mehrere webpackete erstellt sind.

Gibt es möglichkeit irgendwie präfixe zu setzen ??

beispiel: domain.ltd ist webpacket
ftp1 login (standart)= domain.ltd
ftp2 login (fals erstellt wird) domain.ltd2
ftp3 login domain.ltd3 (es kann auch präfixe am anfang gesetzt werden.

das selbe auch für mysql user für phpmyadmin logn berreich.

Ich denke die Idee dahinter ist, dass jeder Kunde selber entscheiden kann wie seine FTP und MySQL Loginuser heissen sollen resp. was diese für ein Passwort bekommen.

Persönlich finde ich das auch besser so, ich mag es nicht wenn ich alles vordefinierte Logins mit Passwörtern bekomme und dann jedes ggf. noch anpassen muss nach meinem Geschmack.

Zusätzlich würde mit so einem "Standard" eine indirekte Sicherheitslücke geschnitzt werden... so nach dem Prinzip "Oha das ist ISPCP, da wird sicher der Login XXX definiert sein. Aus meiner Sicht ein ziemlicher Blödsinn.

This post was last modified: 06-09-2008 12:32 AM by Kilrathy.

Nicht wirklich, wenn ich einen webpacket erstelle muß ich einen Domain angeben, und dieser Domain ist dan für diese Webpacket das Loginname

also kann es doch auch gleich für Ftp und Mysql auch sein oder ??

du bekommst aber vordefinierte Login angegeben, passwörter kann man ja ändern ohne probleme.

Warum den sicherheitslücke ?? unter Confixx und andere control panells ist es ja auch so und stellt keine sicherheitslücke dar, 2. unter ispCP gibt es login schutz, wenn man 5 mal falsch eintippt wird man für halbe stunde gesperrt

Wie gesagt es ist schwiriger das ganze webpacket mit dazugehörigen passwörter einen überblick bekommt.

Seh ich aber auch so das es besser ist wenn man die Usernamen selber festlegen kann.

Und die mögliche Sicherheitslücke seh ich ebenfalls, da gibts dann wieder genug mit username = passwort ;-)

Wenn an der Stelle eine Änderung dann eher in die Richtung das der Benutzername nicht zwingend der domainname ist.

das währe auch nicht schlecht, aber wie gesagt meine Ansicht währe immer noch wegen Ordnung am Arbeitsplatz Präfixe

Da Stellt sich aber wie immer die Frage, wie sollten diese Präfixe aussehen?
Jeder hat da so seine Eigenen Vorstellungen...ich bin froh das ich da an kein system gebunden bin was mich da einengt.
was aber wirklich sehr hübsch wäre wenn man den kunden login wirklich von domain namen trennen würde.

z.B. dein loginname (wenn es möglich ist nicht domaingebundene) dahinter dann halt "_1" oder so etwa das ganze für mysql und ftp dann halt auch,

also ich hatte mir das so vorgestellt, wenn ich eine Kunde erstelle, sollte ich beliebige loginnamen vergeben können. mit der Loginname soll es aber dann auch ftp und mysql zugänge erstellt werden, und wenn der Kunde mehrere login's für ftp und mysql brauchen sollte dann eben mit der Loginname von ersteltem Kunde dahinter oder davor halt präfixe geben.

Ich gebe fabe recht, jeder Administrator und jeder Endbenutzer hat seine eigenen Ideen von Benutzernamen Handling. Ich persönlich würde nie domain.tld_1, domain.tld_2 verwenden... nur schon weil ich das bildlich hässlich finde

Wie gesagt, da kann man jetzt wirklich stunden diskutieren, wer was warum besser findet.

Aber jo Defaultusername != Domain wäre irgendwie ganz nett aber aus meiner Sicht nicht zwingend.

ich persöhnlich finde es nicht schlecht zusätzlich die kundennummer als login
benutzen zu können.

[senfdazugeb]

mfg

kundennummer wird jedoch nicht automatisch vergeben und ist somit bei vielen kunden leer, da es kein Pflichtfeld ist.