Kamailio als Proxy

[Oliver Timm]

Hallo,

 

wenn ich in der Gateway.ini einen Eintrag für den Kamailio mache, kommen die Anrufe zwar rein, allerdings mit dem Fehler Authentifiation_request 407.

 

Hier steht die From-URI:

EXECUTE sofia/gemeinschaft/+49...@x.x.x.x respond(407 192.11.12.21)

Hier steht die To-URI:

2013-01-11 12:35:33.069533 [DEBUG] mod_sofia.c:2356 Challenging call +49x...@10.0.2.12

 

x.x.x.x = externe IP vom Provider nicht von Kamailio

192.11.12.21 = Freeswitch

10.0.2.12 = Kamailio

 

Kann man FS dazu bewegen diesen Anruf anzunehmen?

 

Gateway.ini

[k_proxy]
profile = gemeinschaft
proxy = 10.0.2.12
;proxy = x.x.x.x
expire-seconds = 600
register = false
extension = {sip_to_user}
;caller-id-in-from = true

 

Nur wenn die Provider IP eingetragen ist, nimmt FS es an, aber das ist ja Falsch. FS weiß ja eigentlich gar nichts vom Provider.

 

Gruß

Oliver

[Sascha Daniels]

Hi.

Am 11.01.13 14:04, schrieb Oliver Timm:

> Hallo,
> wenn ich in der Gateway.ini einen Eintrag für den Kamailio mache, kommen
> die Anrufe zwar rein, allerdings mit dem Fehler Authentifiation_request 407.
>
> Hier steht die From-URI:
>

> EXECUTE _sofia/gemeinschaft/+49...@x.x.x.x_
> <mailto:sofia/gemeinschaft/+49...@x.x.x.x>respond(407 192.11.12.21)

>
> Hier steht die To-URI:
>
> 2013-01-11 12:35:33.069533 [DEBUG] mod_sofia.c:2356 Challenging call

> _+49x...@10.0.2.12_ <mailto:+49xx...@10.0.2.12>

Die ist natürlich aus der Sicht von Gemeinschaft auch falsch.

>
> x.x.x.x = externe IP vom Provider nicht von Kamailio
>
> 192.11.12.21 = Freeswitch
>
> 10.0.2.12 = Kamailio
>
> Kann man FS dazu bewegen diesen Anruf anzunehmen?

Ich kenne Dein Kamailio Setup natürlich nicht, würde aber behaupten,
dass Du auf dem Kamailio die TO URI umschreiben musst.

Kamailio sollte das INVITE an to:+49x...@192.11.12.21 damit sich der
FS überhaupt zuständig fühlt.

Gruss

Sascha

[Oliver Timm]

Nun steht:

 

variable_sip_to_user: [+49xxx]
variable_sip_to_uri: [+49...@192.11.12.21]
variable_sip_to_host: [192.11.12.21]

da drin, aber FS will nicht annehmen.

Am Freitag, 11. Januar 2013 14:04:48 UTC+1 schrieb Oliver Timm:

Hallo,

 

wenn ich in der Gateway.ini einen Eintrag für den Kamailio mache, kommen die Anrufe zwar rein, allerdings mit dem Fehler Authentifiation_request 407.

 

Hier steht die From-URI:

EXECUTE sofia/gemeinschaft/+49xxx@x.x.x.x respond(407 192.11.12.21)

[Sascha Daniels]

Hi.



Am 11.01.13 14:45, schrieb Oliver Timm:

> Nun steht:
> variable_sip_to_user: [+49xxx]
> variable_sip_to_uri: [+49...@192.11.12.21]
> variable_sip_to_host: [192.11.12.21]
> da drin, aber FS will nicht annehmen.

Unter Umständen wird es nicht ohne grössere Änderungen gehen.

Eine Variante wäre sicherlich einen authuser und ein passwort zu setzen,
mit dem sich dann der Kamailio authentifizieren kann.

Die andere Variante ist hier beschrieben und könnte umgebaut werden.

http://kb.asipto.com/freeswitch:kamailio-3.1.x-freeswitch-1.0.6d-sbc

Das entspricht nicht ganz Deinem Setup, man könnte aber das externe
profil umbauen und generell nur über den Proxy gehen.

Gruss

Sascha

[Sascha Daniels]

Hi.

Viel zu kompliziert gedacht!

Bei Kamailio registrar.so laden, User anlegen und Freeswitch sich
registrieren lassen.

Das sollte genau so funktionieren.

Gruss

Sascha


Am 11.01.13 14:59, schrieb Sascha Daniels:

[Oliver Timm]

Hi,

 

dann muss aber am Kamailio sehr viel hinzugefügt werden. Kann man den Proxy in der Gateway. ini nicht auf eine andere Variable setzen oder kann der Kamailio einfach für einen Trusted Host sein?

 

Gruß

[Sascha Daniels]

Hi.

Am 11.01.13 15:28, schrieb Oliver Timm:

> Hi,
> dann muss aber am Kamailio sehr viel hinzugefügt werden. Kann man den
> Proxy in der Gateway. ini nicht auf eine andere Variable setzen oder
> kann der Kamailio einfach für einen Trusted Host sein?

Je länger ich über die Sache nachdenke, je mehr komme ich zu dem
Entschlus, dass es auch ohne Änderung gehen muss!

Eine Patton Smartnode oder eine Berofix Box werden in den meisten Fällen
auch ohne Auth angebunden.

Siehe: https://github.com/amooma/GS5/wiki/1.-Berofix

Jetzt klingelt es auch langsam bei mir!

Aus Deiner 1. Mail:

------

Nur wenn die Provider IP eingetragen ist, nimmt FS es an, aber das ist
ja Falsch. FS weiß ja eigentlich gar nichts vom Provider.

------

Der Freeswitch erwartet natürlich auch 10.0.2.12 in der From URI!


Wie einfach es ist das from sauber hin und wieder zurück zu schreiben
hängt jetzt vom Kamailio Setup ab.

Gruss

Sascha

[Oliver Timm]

Hi,

 

leider Fehlanzeige, im FROM und TO stehen die richtigen IP Adressen.

 

in der variable_sip_contact_host muss die IP vom Kamailio drin stehen.

 

Bei einer Berofix oder Patton ist die ja auch das 1. SIP Gerät in der Kette, deswegen funktioniert es. Bei mir ist ja der Kamailio nicht das 1. SIP Gerät in der Kette, da gabs ja noch den Provider davor.

 

Gruß

Oliver

[Sascha Daniels]

Hi.

Am 11.01.2013 um 16:23 schrieb Oliver Timm <in...@olli-t.de>:

Hi,

 

leider Fehlanzeige, im FROM und TO stehen die richtigen IP Adressen.

 

in der variable_sip_contact_host muss die IP vom Kamailio drin stehen.

 

Bei einer Berofix oder Patton ist die ja auch das 1. SIP Gerät in der Kette, deswegen funktioniert es. Bei mir ist ja der Kamailio nicht das 1. SIP Gerät in der Kette, da gabs ja noch den Provider davor.

 

Auch die contact uri könnte man umschreiben, ist aber sicher nicht sauber.

Scheinbar kann man den auth-calls Parameter nicht nur im Profil setzen.

http://freeswitch-users.2379917.n2.nabble.com/trunk-without-authentication-td6165074.html

Kann aber sein, das man dazu noch acls einbauen muss.

Wie das geht, findest Du im GS4 code.

Ich würde sonst mal auf der Freeswitch Liste fragen.

Gruss Sascha

[Oliver Timm]

Hi,

 

das mit dem ACL hab ich auch schon gelesen.

 

Kann man das einfach so einbauen, dass alles andere noch läuft?

 

Gruß

OT

[Oliver Timm]

Hi,

 

ich verstehe nicht ganz, wo ich das mit dem ACL einbinden soll.

 

Ich kann in die sofia.ini keine XML Struktur einkopieren.

 

     <list name="domains" default="deny">
       <node type="allow" domain="$${domain}"/>
       <node type="allow" cidr="IP/32"/>
     </list>

 

Was wäre mit dem Parameter allow-proxy-acl = IP/32 

 

Gruß
OT

 

Soll ich es nur in die sofia.ini einfügen und

[Stefan Wintermeyer]

2013/1/14 Oliver Timm <in...@olli-t.de>:

> ich verstehe nicht ganz, wo ich das mit dem ACL einbinden soll.

Ich möchte nicht unhöflich sein, aber das hier ist die GS5 und nicht
die Kamailio Mailingliste.

Nach einer gewissen Grauzone bewegt sich dieser Thread eindeutig auf
die Kamailio Mailingliste zu.

Stefan

--
AMOOMA GmbH - Bachstr. 124 - 56566 Neuwied --> http://amooma.de
Geschäftsführer: Stefan Wintermeyer, Handelsregister Montabaur B14998

Bücher: http://das-asterisk-buch.de - http://ruby-auf-schienen.de

[Sascha Daniels]

Hi.


Am 14.01.13 14:07, schrieb Oliver Timm:

> Hi,
> ich verstehe nicht ganz, wo ich das mit dem ACL einbinden soll.
> Ich kann in die sofia.ini keine XML Struktur einkopieren.
> <list name="domains" default="deny">
> <node type="allow" domain="$${domain}"/>
> <node type="allow" cidr="IP/32"/>
> </list>
> Was wäre mit dem Parameter allow-proxy-acl = IP/32

Ich kann das im Moment nur theoretisch beantworten, da ich keine Zeit
habe das im Labor nach zu bauen.

In der freeswitch.conf findest Du diese Zeilen:

<configuration name="acl.conf" description="Network Lists">
<network-lists>

<list name="domains" default="deny">

<node type="allow" cidr="127.0.0.1/32"/>
</list>
</network-lists>
</configuration>


Mach da mal das hier draus:

<configuration name="acl.conf" description="Network Lists">
<network-lists>

<list name="domains" default="deny">

<node type="allow" cidr="127.0.0.1/32"/>
<node type="allow" cidr="KAMAILIO_IP/32"/>
</list>
</network-lists>
</configuration>


Wenn das nicht geht, fällt mir erstmal nichts mehr ein und ich würde
Dich, wie Stefan, auf die Kamailio Liste verweisen um registrar in
Kamailio ein zu bauen.

Gruss

Sascha

[Oliver Timm]

Hi,

 

kann man in den Quellcode vom FS schauen bzw habt ihr den von der 1.1.Beta1 noch?

 

sofia.c
/*
* if network_ip is a proxy allowed to send calls, check for auth
* ip header and see if it matches against the inbound acl
*/

 

evtl. ist das auskommentiert.

Gruß

[Sascha Daniels]

Hi.

Am 14.01.13 16:07, schrieb Oliver Timm:
> Hi,

> kann man in den Quellcode vom FS schauen bzw habt ihr den von der
> 1.1.Beta1 noch?
> sofia.c
> /*
> * if network_ip is a proxy allowed to send calls, check for auth
> * ip header and see if it matches against the inbound acl
> */

Das kann nur Julian beantworten. Der baut die Pakete.

Gruss

Sascha

[Julian Pawlowski]

Na nichts leichter als das ;-))

http://git.freeswitch.org/git/freeswitch/tree/src/mod/endpoints/mod_sofia/sofia.c

Gruß

Julian 

[Oliver Timm]

Hi,

 

Ich meint eher nicht den aktuellen Code sondern aus dem FS für Gemeinschaft compiliert wurde.

 

Aber ich habs jetzt anders gelöst, habe die sip_contact_host variable im dailplan für das Gateway geändert und schicke mit Kamailio einen X-Header.

 

Gruß
Oliver.

[Julian Pawlowski]

On Tuesday, January 15, 2013 4:50:44 PM UTC+1, Oliver Timm wrote:

Ich meint eher nicht den aktuellen Code sondern aus dem FS für Gemeinschaft compiliert wurde.

Ich weiß leider nicht welche Software du mit 1.1.Beta1 meinst.

Gemeinschaft 5.0.2 wurde mit FreeSwitch Revision 01c1195ef403dbc10424147f9b39618dbb2db4d6 gebaut, die sofia.c sah zu diesem Zeitpunkt vermutlich so aus:

http://git.freeswitch.org/git/freeswitch/tree/src/mod/endpoints/mod_sofia/sofia.c?r=01c1195ef403dbc10424147f9b39618dbb2db4d6

(bin nicht sicher ob die URL Syntax für cgit so korrekt ist).

Gruß

Julian

[Oliver Timm]

Achso,

 

ich habe noch die FS Version 1.1.Beta1 auf meiner Anlage.

 

Kann ich die "einfach" updaten? Oder sollte ich sie deinstallieren und nach dem install Script installieren?

Problem ist, ich brauche nen anderen Kernel, da ich die Anlagen auf Hyper-V betreibe.

 

Gruß

Oliver

[Stefan Wintermeyer]

2013/1/15 Oliver Timm <in...@olli-t.de>:

> Kann ich die "einfach" updaten?

Nein.

> Oder sollte ich sie deinstallieren und nach
> dem install Script installieren?

Wir arbeiten intensiv an der 5.1. Ich würde an Deiner Stelle die 2-3
Tage noch warten. Vielleicht ist morgen schon ein lauffähiges Nightly
Build fertig.

> Problem ist, ich brauche nen anderen Kernel, da ich die Anlagen auf Hyper-V
> betreibe.

hmmm... ich bin mir nicht sicher, ob es da zu einem Henne-Ei-Problem
kommt. Das Install-Skript ist bei der 5.1 nicht mehr da.

[Julian Pawlowski]

On Tuesday, January 15, 2013 7:36:57 PM UTC+1, Oliver Timm wrote:

Kann ich die "einfach" updaten? Oder sollte ich sie deinstallieren und nach dem install Script installieren?

Welches Install-Script? Es gibt kein Install-Script für GS.

 

Problem ist, ich brauche nen anderen Kernel, da ich die Anlagen auf Hyper-V betreibe.

Hyper-V heißt nicht zwangsweise einen anderen Kernel nutzen zu müssen. Du kannst das originale GS5 Image sicherlich ohne Paravirtualisierung laufen lassen (ohne nennenswerte Performanceverluste).

Gruß

Julian

[Peter Kozak]

On 01/15/2013 07:44 PM, Julian Pawlowski wrote:
> Kann ich die "einfach" updaten? Oder sollte ich sie deinstallieren
> und nach dem install Script installieren?
>
>

> Welches Install-Script? Es gibt kein Install-Script f�r GS.

Es gab aber vor kurzem noch eines :)


Mit freundlichen Gr��en

Peter Kozak

--

AMOOMA GmbH - Bachstr. 124 - 56566 Neuwied --> http://www.amooma.de
Gesch�ftsf�hrer: Stefan Wintermeyer, Handelsregister Montabaur B14998

B�cher: http://das-asterisk-buch.de - http://ruby-auf-schienen.de

[Stefan Wintermeyer]

2013/1/15 Peter Kozak <peter...@amooma.de>:
>> Welches Install-Script? Es gibt kein Install-Script für GS.

>
> Es gab aber vor kurzem noch eines :)

Sonnenwinde! ;-)

Stefan

--
AMOOMA GmbH - Bachstr. 124 - 56566 Neuwied --> http://amooma.de
Geschäftsführer: Stefan Wintermeyer, Handelsregister Montabaur B14998

Bücher: http://das-asterisk-buch.de - http://ruby-auf-schienen.de

[Julian Pawlowski]

On Tuesday, January 15, 2013 7:51:54 PM UTC+1, Stefan Wintermeyer wrote:

2013/1/15 Peter Kozak <peter...@amooma.de>:
>> Welches Install-Script? Es gibt kein Install-Script für GS.
>
> Es gab aber vor kurzem noch eines :)

Sonnenwinde! ;-)

;-)

Gut, dann sind wir so fair zu sagen: FreeSwitch kannst du, Oliver, bei deiner Installation einfach updaten. Vorher oder hinterher ist egal, entscheidend ist eine lauffähige Version.

Gruß

Julian 

[Oliver Timm]

Hi

 

Ich weiß nicht welchen Kernel ihr mitliefert. Meine Installation mit Debian hatte einen zu alten Kernel.

Der läuft, aber er unterstützt die Netzwerkkarte nur sehr schlecht und da leidet die Performance erheblich drunter.

 

Gruß

Oliver

[Julian Pawlowski]

On Tuesday, January 15, 2013 8:36:59 PM UTC+1, Oliver Timm wrote:

Ich weiß nicht welchen Kernel ihr mitliefert. Meine Installation mit Debian hatte einen zu alten Kernel.

Alles mit Absicht Debian Squeeze Standard, also 2.6.32-5-686.

Wenn da was schlecht läuft am Netzwerk, mal mit dem Debian Team in Verbindung setzen.

Bald machen wir aber auch Wheezy.

Gruß

Julian 

[Oliver Timm]

Ich wollte mir die Arbeit des Kernel kompilieren sparen und halt nur Freeswitch austauschen ;) im Kernal 3.5 sind halt die Hyper-V Treiber schon drin und es läuft alles smart.

 

Da Stefan geschrieben hat, es gibt kein Install Script mehr, sind dann vermutlich auch die Infos aus dem Script alt.

http://xx.xx.xx.xx/GS5/freeswitch_1.1.beta2.1-1_i386.deb

 

Es wäre dann also vermutlich am besten auf 5.1 zu warten, dann den Kernel neu zu Kompilieren, alle anderen Tools zu installieren, die man so brauch und dann GS5 weiterhin über git pull upzudaten, richtig?

 

Gruß
Oliver

[Julian Pawlowski]

On Tuesday, January 15, 2013 9:06:10 PM UTC+1, Oliver Timm wrote:

Ich wollte mir die Arbeit des Kernel kompilieren sparen und halt nur Freeswitch austauschen ;) im Kernal 3.5 sind halt die Hyper-V Treiber schon drin und es läuft alles smart.

Gibt es dann mit GS5 auf Wheezy.

 

Da Stefan geschrieben hat, es gibt kein Install Script mehr, sind dann vermutlich auch die Infos aus dem Script alt.

http://xx.xx.xx.xx/GS5/freeswitch_1.1.beta2.1-1_i386.deb

Vermutlich ja, zumindest wird es diese Downloads wahrscheinlich nicht mehr auf Dauer dort geben, da sie ansich schon einfach veraltet sind.

GS5 wird sich an die offiziellen FreeSwitch Pakete hängen, sobald es diese zuverlässig gibt (ist momentan noch nicht der Fall). Bis dahin bauen wir selbst, was momentan sogar dem aktuellen Master-Branch entspricht (ggf. wechseln wir noch auf "stable" zurück, mal sehn).

  

Es wäre dann also vermutlich am besten auf 5.1 zu warten, dann den Kernel neu zu Kompilieren, alle anderen Tools zu installieren, die man so brauch

 

Wenn das dein Weg ist, ok. Support wird dir für dieses System dann vermutlich nicht mehr geboten werden können, selbst auf der Liste tun wir uns dann mit so weitreichenden eigenen Änderungen eher schwer. Man kann halt unmöglich abschätzen was da noch alles dran hängt.

GS5 wird als fertiges ISO zum Download angeboten mit der Option, dass sich jeder (mit etwas Kenntnis bzwl einlesen) auch selbst ein ISO bauen kann.

Inoffizielle Veränderungen am fertig installierten System (oder an den Scripten, die das ISO bauen), können unmöglich vorausgesehen werden und verhindern eine zuverlässige Basis, um auftretende Fehler sicher und zuverlässig reproduzieren und dann beheben zu können.

Mein Tipp (für die Zukunft): Nimm das offizielle ISO so wie es ist und ändere so wenig wie möglich selbst daran. Wenn dir etwas fehlt und du es als für die Allgemeinheit interessant hältst, dann schreibe dafür am Besten ein Script, welches alle Änderungen automatisch vornimmt. Zum einen kannst du damit deine eigenen Änderungen dokumentieren und zum anderen hast du die Möglichkeit das Script offiziell einzureichen, damit es ggf. als Grundlage dafür dienen kann diese Funktion in GS5 direkt von Haus aus mit einzubauen. Davon hätten dann alle was: Du hättest deine Funktion offiziell drin, sie würde supported werden und andere Nutzer profitieren ebenso davon.

und dann GS5 weiterhin über git pull upzudaten, richtig?

 

Die kommende GS5 wird verschiedene Möglichkeiten bieten, wie du eine vorhandene Installation auf eine neue Version updaten/migrieren kannst. Mehr dazu gibts dann sicherlich auf dieser Liste und der Website ;-)

Ein Git-pull eigenmächtig zu machen wird nicht empfohlen (das allein reicht nicht aus), es hängt einfach zu viel dran.

Gruß

Julian

[Oliver Timm]

Hi,

 

ich weiß, dass Kernel Updates nicht ohne sind, aber Debian läuft auf Hyper-V wirklich bescheiden im Netzwerk. Und da ihr euch für Debian entschieden habt brauch ich halt die Hyper-V Treiber. Ich glaube kaum, dass die neue Debian Version den 3.5 Kernel dabei haben wird oder? Für Redhat gibt's halt Treiber, ohne das man den Kernel verändern muss.

 

Das einzige was ich installiere ist MC und Webmin, mehr brauch ich nicht.

 

Gruß

Oliver

[Julian Pawlowski]

Hallo Oliver,

On Tuesday, January 15, 2013 9:38:53 PM UTC+1, Oliver Timm wrote:

Und da ihr euch für Debian entschieden habt brauch ich halt die Hyper-V Treiber.

Dann empfehle ich eher den Backport-Kernel in Squeeze zu installieren, das ist zudem viel einfacher:

"Debian 6.0 mit squeeze-backport Kernel 3.2.15-1 (siehe Debian Bug report logs - #661318 Possibility of integrating newer Hyper-V paravirt)"

Ich schau mal ob wir das nicht von Haus aus so machen.

 

Ich glaube kaum, dass die neue Debian Version den 3.5 Kernel dabei haben wird oder?

Der entsprechende Hyper-V Teil wurde auf den Wheezy-Kernel portiert:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684283#39

 

Für Redhat gibt's halt Treiber, ohne das man den Kernel verändern muss.

Das liegt einfach nur daran, dass RHEL6 neuer ist als Debian Squeeze.

Das einzige was ich installiere ist MC und Webmin, mehr brauch ich nicht.

Ok, das geht ja ;-)

Gruß

Julian

[Oliver Timm]

Hi Julian,

Am Mittwoch, 16. Januar 2013 09:52:57 UTC+1 schrieb Julian Pawlowski:

Hallo Oliver,

On Tuesday, January 15, 2013 9:38:53 PM UTC+1, Oliver Timm wrote:

Und da ihr euch für Debian entschieden habt brauch ich halt die Hyper-V Treiber.

Dann empfehle ich eher den Backport-Kernel in Squeeze zu installieren, das ist zudem viel einfacher:

"Debian 6.0 mit squeeze-backport Kernel 3.2.15-1 (siehe Debian Bug report logs - #661318 Possibility of integrating newer Hyper-V paravirt)"

Ich schau mal ob wir das nicht von Haus aus so machen.

 

Ich glaube kaum, dass die neue Debian Version den 3.5 Kernel dabei haben wird oder?

Der entsprechende Hyper-V Teil wurde auf den Wheezy-Kernel portiert:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684283#39

 

Das habe ich gestern auch gelesen, die Frage ist, wann es fertig ist. 

 

Für Redhat gibt's halt Treiber, ohne das man den Kernel verändern muss.

Das liegt einfach nur daran, dass RHEL6 neuer ist als Debian Squeeze.

Das einzige was ich installiere ist MC und Webmin, mehr brauch ich nicht.

Ok, das geht ja ;-)

 

Denke ich auch :) 

Gruß

Julian

 

Gruß

Oliver 

[Julian Pawlowski]

On Wednesday, January 16, 2013 9:52:57 AM UTC+1, Julian Pawlowski wrote:

Dann empfehle ich eher den Backport-Kernel in Squeeze zu installieren, das ist zudem viel einfacher:

"Debian 6.0 mit squeeze-backport Kernel 3.2.15-1 (siehe Debian Bug report logs - #661318 Possibility of integrating newer Hyper-V paravirt)"

Ich schau mal ob wir das nicht von Haus aus so machen.

Ich habe jetzt mal den 3.2er Kernel mit Hyper-V Support testweise in den Nightly Build eingebaut.

Gruß

Julian

[Julian Pawlowski]

Hallo Oliver,

On 16.01.2013, at 11:16, Oliver Timm <in...@olli-t.de> wrote:

Der entsprechende Hyper-V Teil wurde auf den Wheezy-Kernel portiert:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684283#39

 

Das habe ich gestern auch gelesen, die Frage ist, wann es fertig ist.

Was das Debian Team angeht weiß ich das natürlich nicht.

Was GS5 angeht, so sieht es für ein erstes Wheezy Testimage ganz gut aus, sobald ein letzter (jedoch entscheidender) Bug bei der Netzwerkkonfiguration behoben ist.

Gruß

Julian

[Oliver Timm]

Hallo Julian,

Dann warte ich mal gespannt auf das Testimage :) wird das bekanntgegeben? Hat nichts mit GS5.1 zu tun, oder? 

Gruß

Julian

 

Gruß
Oliver 

[Stefan Wintermeyer]

2013/1/16 Oliver Timm <in...@olli-t.de>:

> Dann warte ich mal gespannt auf das Testimage :) wird das bekanntgegeben?
> Hat nichts mit GS5.1 zu tun, oder?

Doch, das ist GS 5.1. Wir bauen jede nach ein Nightly Build. Das kann man unter
http://amooma.de/gemeinschaft/gs5 downloaden. Morgen früh also.

[Oliver Timm]

Hallo Stefan,

 

um nichts falsch zu verstehen.

Morgen früh gibt es das Testimage ( GS 5.1 ) mit Wheezy?

 

Gruß
Oliver

[Julian Pawlowski]

On Wednesday, January 16, 2013 12:58:12 PM UTC+1, Oliver Timm wrote:

um nichts falsch zu verstehen.

Morgen früh gibt es das Testimage ( GS 5.1 ) mit Wheezy?

Nein, GS 5.1 basiert weiterhin auf Squeeze, hat aber testweise einen 3.2er Kernel eingebaut.

Morgen früh kannst du es dir ansehen.

Gruß

Julian

[Oliver Timm]

Moin Julian,

habs gerade mal aufgesetzt. Die Netzwerkkarte wird jetzt erkannt.

Das heißt für mich nur noch nano, mc und webmin nachinstallieren + firewallport für webmin hinzufügen.

Danke und Gruß

Oliver 

[Julian Pawlowski]

Hallo Oliver,

On Friday, January 18, 2013 11:05:23 PM UTC+1, Oliver Timm wrote:

habs gerade mal aufgesetzt. Die Netzwerkkarte wird jetzt erkannt.

Das heißt für mich nur noch nano, mc und webmin nachinstallieren + firewallport für webmin hinzufügen.

Prima, danke für das Feedback!

In Squeeze werde ich den Kernel allerdings u.a. aus Platzgründen erstmal wieder aus dem Image nehmen. Aber man kann ihn dann mit nur einem Befehl nachinstallieren, sofern man ihn braucht.

Alles besser als noch selbst was kompilieren zu müssen ;-)

Gruß

Julian 

[Julian Pawlowski]

On Saturday, January 19, 2013 3:27:55 PM UTC+1, Julian Pawlowski wrote:

In Squeeze werde ich den Kernel allerdings u.a. aus Platzgründen erstmal wieder aus dem Image nehmen. Aber man kann ihn dann mit nur einem Befehl nachinstallieren, sofern man ihn braucht.

Ab dem morgigen Nightly Build kann man den neueren Kernel so nachinstallieren:

gs-addon.sh install linux-kernel-3.2

Gruß

Julian