From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: OpenVPN no more --client-(dis)connect scripts can be executed Date: Mon, 12 Oct 2020 13:28:16 +0200 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1259130399496215408==" List-Id: --===============1259130399496215408== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi On 12/10/2020 12:45, Michael Tremer wrote: > Hi, >=20 >> On 11 Oct 2020, at 15:16, ummeegge wrote: >> >> Hi all, >> sorry for the late replay but things are going to be a little chaotic >> this days :-) . >> >> Am Donnerstag, den 08.10.2020, 19:18 +0200 schrieb Adolf Belka: >>> Hi Michael, >>> >>> I suspect you are right about my optimism but that is my nature :) >> That=C2=B4s great :-) , would you like to step into some more testing roun= ds :D --> >> https://community.ipfire.org/t/openvpn-2-5-development-version/2173 >> ? >=20 > Can we not keep development stuff on the development list please? >=20 > community.ipfire.org is a support portal and loads of people download all s= orts of things and crash their systems with it, or never update them. I am al= l for having people involved in testing, but only after we have reached some = sort of standard that is good enough for a larger group of testers. >>> >>> >>> Regards, >>> Adolf. >>> >>> >>> On 08/10/2020 16:26, Michael Tremer wrote: >>>> Hello boys, >>>> >>>> Great conversation here, but unfortunately this is going to be >>>> messy... >>>> >>>>> On 8 Oct 2020, at 14:23, Adolf Belka >>>>> wrote: >>>>> >>>>> Hi Erik, >>>>> >>>>> On 08/10/2020 10:11, ummeegge wrote: >>>>>> Good morning Michael, >>>>>> >>>>>> Am Mittwoch, den 07.10.2020, 13:38 +0100 schrieb Michael >>>>>> Tremer: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> That reads awful. >>>>>>> >>>>>> >>>>>> yes indeed it also feels exactly like this if there is the need >>>>>> to >>>>>> handle it for the community in a good proper way. >>>>>> I really can not understand why directives like --cipher needs >>>>>> to be >>>>>> changed to --data-ciphers, from the OpenVPN perspective it >>>>>> might be a >>>>>> better understanding if there is a difference between control >>>>>> channel >>>>>> and data channel encryption but from the users point of view >>>>>> with >>>>>> several hundreds clients it is overkill since every client >>>>>> config needs >>>>>> then to be changed. >>>>>> >>>>> >>>>> I am not sure that this is as major an issue as you indicate, >>>>> although I could very easily be wrong, so I thought it was >>>>> worthwhile to give my input. >>>>> >>>>> Firstly, the --cipher option has been indicated that it will be >>>>> deprecated ( >>>>> https://community.openvpn.net/openvpn/wiki/CipherNegotiation) but >>>>> without any date. It does not show up yet in the Deprecated >>>>> options page ( >>>>> https://community.openvpn.net/openvpn/wiki/DeprecatedOptions) >>>>> This states "we will try to keep an up-to-date list of all >>>>> options we have deprecated, when they will be removed, the >>>>> new alternative approach and the reasoning behind removing the >>>>> option". >>>> >>>> So, I suppose we will have to re-implement the whole cipher >>>> selection on our side then. We will have to remove --ncp-disable >>>> and =E2=80=94cipher and start adding =E2=80=94data-ciphers. A select box= where >>>> multiple algorithms can be chosen (like in IPsec) is probably the >>>> best option, and we can select AES-{256,128}-{GCM,CBC} and >>>> potentially BF if we find a user that is still on it. We would have >>>> to deprecate the latter already though. >>>> >>>> We should then be able to support a maximum of clients according to >>>> this >>>> https://community.openvpn.net/openvpn/wiki/CipherNegotiation#Serverversi= on2.5 >> >> As far as i can see now with the testing results from RC2, we can run >> the old configurations like before which includes a lot of deprecation >> warnings in the logs but it should nevertheless work... The rest, like >> Michael mentioned it, should be done better earlier than later. >> But besides of that i am really really not sure what happens with the >> actual version on Smartphones since i do not uses such. >=20 > I do not think that too many people use OpenVPN on mobile devices because i= t does not provide a native client and all clients that I have tried were a l= ittle fiddly. I use OpenVPN on my Samsung phone. I am using the OpenVPN for Android app and= that seems to work very well for me. So I would be happy to test out my mobi= le link on any updates to OpenVPN that reach the appropriate testing stage. >=20 > I think we should start dropping old crypto now. This is an easy change and= we can get people on AES. That will be with us for the foreseeable future. >=20 > I am happy to either show a warning for about 6 months and to encourage peo= ple to move away from BF, DES, SEED, etc. And then remove these in around Mar= ch-April time for good. We have already marked those ciphers as weak and I wo= uld propose to remove all of them. >=20 >>>> >>>> Under no circumstances is it feasible that we require the client to >>>> change. We have users out there with hundreds and hundreds of >>>> connections. It simply is not possible for them to change them. It >>>> will take years. OpenVPN simply seems to be forgetting this. >>>> >>>>> I think that means that it will likely not be removed till >>>>> OpenVPN v2.7 at earliest. >> It was a fast way from 2.3 to 2.4 and am sure the way to 2.7 will be >> done faster and there are indeed a lot of configurations out there >> which uses --ns-cert-type even there are warnings findable in the WUI. >> >> Apart from that according to the log messages i think we have also some >> stuff to solve until 2.6 like the --ncp-disable deprecation --> >> https://community.ipfire.org/t/openvpn-2-5-development-version/2173/2 >> ? >=20 > Yes, let=E2=80=99s start with the ciphers/NCP ones first, because that will= be released earlier. >=20 > Changing ns-cert-type on the server side should still allow clients to conn= ect that use an older version, am I right? >=20 >> >>>> >>>> Potentially, but we need to prepare ourselves and our users before >>>> that. Whenever we release 2.7, it will simply be too late, because >>>> then the deprecated options have already gone. We need to act now, >>>> and make sure that a client with a modern configuration can connect >>>> to a server - now and in the future. >>>> >>>> I find it brilliant that OpenVPN has a whole page to describe the >>>> deprecation of one option. Although I agree with the cipher >>>> negotiation, there has to be a migration path. >> Yes, me too.. >> >>>> >>>>> Secondly >>>>> https://github.com/OpenVPN/openvpn/blob/master/doc/man-sections/cipher-= negotiation.rst >>>>> states "OpenVPN 2.5 will only allow the ciphers specified in -- >>>>> data-ciphers. To ensure backwards compatibility also if a >>>>> cipher is specified using the --cipher option it is automatically >>>>> added to this list. If both options are unset the default is AES- >>>>> 256-GCM:AES-128-GCM." >> Like above explained, The last tests here (RC2) did not have problems >> with the --cipher directive even the log fires the warning that it is >> deprecated... but am not sure how the 2.5.0 release behavior is since >> the beta releases do have noticable changes to the RC ones and again i >> have no experiences with Smartphones and the new version... >> >>>>> >>>>> In my OpenVPN for Android client this is what happens. --cipher >>>>> has AES-256-GCM from my client config that I transferred from >>>>> IPFire but also has --data-ciphers with AES-256-GCM:AES-128- >>>>> GCM:AES-256-GCM, so the contents of my --cipher have been copied >>>>> across to the end of --data-ciphers. >> That might be interessting if the server do not reflects this ? My >> testings involves only PCs/laptops which uses the config files without >> own interactions/enhancements... >=20 > That is not a big problem. Just make clear what you tested and what you cou= ld not test when posting patches. Then, somebody else can fill in the gaps. >=20 >> >>>>> >>>>> If users are using a strong encryption, such as AES-256-GCM then >>>>> this is the default anyway. If people have a weaker encryption in >>>>> --cipher such as BF-CBC, CAST or RC2, then currently that will >>>>> also be copied across to --data-ciphers but from OpenVPN v2.6 >>>>> those encryptions will not be copied across as they have been >>>>> deprecated as too weak for some time. The other encryptions will >>>>> still be copied across from --cipher to --data-cipher. >> If someone uses those algorithms they do not care really about >> security, IPFire lined that out as "(weak)" but in fact they are >> broken, but the differences between Smartphones and regular clients are >> may important to focus on... >> >>>>> >>>>> Eventually, when --cipher is removed (timing still to be defined) >>>>> then users may need to ensure that --data-ciphers contains the >>>>> encryptions they want to use if they are not using the default of >>>>> AES-256-GCM and AES-128-GCM on the IPFire OpenVPN server. >> There is meanwhile more, 2.5 offers also CHACHA20-POLY1305 for the data >> channel but also BLAKE2 and SHA3 for the controll channel which are >> potential candiates for a future default ?! >=20 > To be honest, I do not care about them. AES has the advantage of hardware a= cceleration on all platforms and it is probably too early to roll out SHA3 as= default. >=20 > We can add them after we got rid of the legacy ones and finished the NCP mi= gration. Tackle one problem at a time. If we change too many things, we won= =E2=80=99t be able to test things easily. >=20 >>>>> >>>>> Having a blog post about the removal of BF-CBC and CAST5-CBC with >>>>> OpenVPN v2.6 and the need for anyone using those ciphers would be >>>>> a good idea because anyone concerned about their VPN security >>>>> would not want to be using those ciphers any more. >> May a good idea even this has been meanwhile longer time ago announced >> but also outlined in the WUI. >> >>>>> >>>>> So, yes the deprecation of --cipher will eventually give a need >>>>> to update client configs if the default strong ciphers are not >>>>> being used but the timing is not yet critical. We need to keep an >>>>> eye on the Deprecated Options page on the OpenVPN Wiki. >>>> >>>> Not critical, but clients are normally not being updated. And if, >>>> very very slowly. >> Exactly! Or in other words, who read the documentation/blog_posts and >> acts like recommended ?! >=20 > Some people do, but it isn=E2=80=99t always possible. In this case: You can= not simply change the cipher unless you can update all your clients at the sa= me time. People=E2=80=99s hands are tied. >=20 >> >>>>> >>>>> Please let me have your feedback, especially if I have made an >>>>> error in my analysis and interpretation. >>>> >>>> No, I think you are just a little bit more optimistic than I am :) >>>> >>>>> >>>>> Regards, >>>>> >>>>> Adolf. >>>>> >>>>> >>>>> >>>>>> Also, if --topology net30 will be dropped by OpenVPN we need to >>>>>> modify >>>>>> every CCD configuration which uses --ifconfig-push out there >>>>>> otherwise >>>>>> we get an >>>>>> >>>>>> Wed Oct 7 17:14:29 2020 /sbin/ip addr add dev tun0 10.18.5.2/- >>>>>> 1 broadcast 255.255.255.254 >>>>>> Error: any valid prefix is expected rather than "10.18.5.2/-1". >>>>>> Wed Oct 7 17:14:29 2020 Linux ip addr add failed: external >>>>>> program exited with error status: 1 >>>>>> Wed Oct 7 17:14:29 2020 Exiting due to fatal error >>>>>> >>>>>> , which logic should we use to distribute the IPs?! Did some >>>>>> tests with >>>>>> new CCD configs and topology subnet but run in other currently >>>>>> not >>>>>> identifiable problems like: >>>>>> >>>>>> Wed Oct 7 17:19:44 2020 /sbin/ip route add 192.168.5.0/24 via >>>>>> 10.25.18.1 >>>>>> Error: Nexthop has invalid gateway. >>>>>> Wed Oct 7 17:19:44 2020 ERROR: Linux route add command failed: >>>>>> external program exited with error status: 2 >>>>>> Wed Oct 7 17:19:44 2020 Initialization Sequence Completed >>>> >>>> This seems to be broken. >>>> >>>> If we change to =E2=80=9Csubnet=E2=80=9D, we would simply lease one IP a= ddress from >>>> the allocated subnet to this client and that is it. >>>> >>>> I could not find anything that tells us that =E2=80=9Cifconfig-push=E2= =80=9D won=E2=80=99t >>>> work any more. However, it currently looks like this for a client: >>>> >>>> ifconfig-push 10.191.0.2 10.191.0.1 >>>> >>>> The first IP address is the one that the user has selected for the >>>> client and the second one is the one that is getting assigned to >>>> the server. >> I think there is more but we should deliver that one may to bugzilla >> then and may it is possibly also a good idea to wait until the release >> and check for potential changes ? >=20 > We should start now on what we can do now. Why wait? >=20 >> >>>> >>>> The documentation says that the second part has to be replaced by >>>> the subnet mask. >>>> >>>> So that means we will have to migrate all those files manually when >>>> the update is being applied. This can all be done on the server and >>>> therefore won=E2=80=99t break the client configuration. Phew. >>>> >>>>>> >>>>>> which seems to be a kernel or an iproute problem on the client >>>>>> system >>>>>> --> >>>>>> https://community.openvpn.net/openvpn/ticket/1086 >>>>>> >>>>>> even it connects. >>>>>> >>>>>> There is a little time for the most stuff left cause this will >>>>>> be >>>>>> initially a problem with OpenVPN version 2.6 , also, the tested >>>>>> 2.5 >>>>>> versions are RCs and so may some changes can happen too but >>>>>> there is >>>>>> currently not much to say from my side except arrgh . >>>>>> >>>>>> >>>>>> >>>>>>> Can we please create individual tickets for the individual >>>>>>> problems >>>>>>> and assign someone to work on those (I assume that would be >>>>>>> you Erik >>>>>>> :D). >>>>>>> >>>>>> >>>>>> Will go for it but as far as i can see we would need possibly >>>>>> some more >>>>>> help, may Alexander is around for the CCD section ? >>>> >>>> Yes, it is a good idea to reach out to him as soon as we have a >>>> plan. >>>> >>>>>>> We need to coordinate this and future-proof OpenVPN as best >>>>>>> as we >>>>>>> can, but it looks like we will break client configuration - >>>>>>> again. >>>>>>> >>>>>> >>>>>> As far as i can see it now, yes we will break client >>>>>> configurations >>>>>> finally with OpenVPN version 2.6 . >>>> >>>> We probably won=E2=80=99t be able to support it all the way back to Core >>>> Update 1. But I suppose we need to try and prepare the currently >>>> issued configuration files so that clients will work when they >>>> update soon. >> 2.5 was working with RC2 also with the conventional configs as far as i >> can see but i haven=C2=B4t tested Smartphones since i do not use them... >> >>>> >>>>>>> If we have to do that and there is no way to avoid it, we >>>>>>> need to >>>>>>> make our users aware of that of course and give the enough >>>>>>> time to >>>>>>> prepare for this. >>>>>>> >>>>>> >>>>>> Yes, we did that before and i hate it to say but probably we >>>>>> need to >>>>>> make this again if the OpenVPN update politics go this way. But >>>>>> may >>>>>> someone here have another idea or i haven=C2=B4t interpret the >>>>>> upcoming >>>>>> changes incorrectly since there is already no manpage/wiki for >>>>>> OpenVPN >>>>>> 2.5 around... >>>> >>>> Questions from me: >>>> >>>> How do we migrate ns-cert-type? >> Create a new PKI with the approrpiate openssl.cnf entries. >> But there was also an idea to manually repair the PKI --> >> >> https://community.ipfire.org/t/solved-manual-repair-pki-on-openvpn-rfc3280= -issue/2326 >> which i haven=C2=B4t test and i am also not a friend of it since it mostly >> includes also the old values of keylengths 1024 bit host and 2048 bit >> for the root certificate --> shouldn=C2=B4t we expand the actual values >> 2048/4096 may too ? >=20 > Oh. This is bad. We need to script the changes then. Otherwise we won=E2=80= =99t be able to encourage users to update. >=20 > Having shorter key lengths is a compromise that we have to make in my opini= on. >=20 >> >>>> >>>> How do we migrate comp-lzo/compress? >> Should we really do this ? Since Voracle OpenVPN disables compression by d= efault --> >> https://community.openvpn.net/openvpn/wiki/VORACLE?__cf_chl_jschl_tk__=3Dc= 269b344bb1a46a9d9ad40cdbca2fa7250a49634-1602424768-0-AZ_zX1wAAsx6JM0SGLkLW4lh= hlE1I77NRrWVdljRXGvS1ijBw5O8mHtjNvPWfPbvr3ruH2YMtPO-Fc8GPgphkW2dQ2NX0karwsEVJ= vusnUcZXdc9rYkLiyuqsfrmfJxOPds9BXCoxPb2jA-6ElbmVE-Hyyp0FwLpa7xw_nw3gOMTDSrHna= LO9uT5_rHdSwn7Z0NhRKtzgf2eSHyNyqSu3Nd_YKk0YKvuLKqEARvIA9TBQlBKwMn6AtiUpUZSg4g= hQutd-u8H4KAI8NKb-N6R0PbV_aNz7MPGTo5nl1Kczx_q >=20 > We cannot change this, because it is not being negotiated between the clien= t and server. So we have to keep it enabled for users where it is currently e= nabled. >=20 > Again, we have no choice. >=20 >> >>>> >>>> We should be fine for the rest. >> :-) >> >>>> >>>> How do we get rid of this ugly certificate warning? >> Which one you mean ? >=20 > The RFC something one at the top. >=20 >> >>>> >>>> Before we start hacking the CGI, should we try to clean up some >>>> code? For example does the whole page not take the /24 format for >>>> subnets. That is a bit annoying. >> Pretty much, am happy if someone comes around with some help with this sin= ce there has been also some work been made, same with the RRD stuff... >> Have also for example outsorted the functions in ovpnmain.cgi and gave the= m a own openvpn-functions.pl like it was done with ids-functions.pl, this cle= aned up the cgi also a little and is already available... >>>> >> >> >> >>>>>> >>>>>> >>>>>>> I cannot even say how annoying this is - again. But we must >>>>>>> try our >>>>>>> best. >>>>>>> >>>>>> >>>>>> I feel you very good am not sure how to handle this without >>>>>> hassle the >>>>>> users around... sad to say but this is not a glorious job. >>>> >>>> Together we will get it done :) >> Great :-) . >>>> >>>> -Michael >>>> >>>>>>> -Michael >>>>>>> >>>>>> >>>>>> Best, >>>>>> >>>>>> Erik >>>>>> >>>>>> >>>>>>>> On 7 Oct 2020, at 11:37, ummeegge >>>>>>>> wrote: >>>>>>>> >>>>>>>> Am Mittwoch, den 07.10.2020, 10:22 +0100 schrieb Michael >>>>>>>> Tremer: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 7 Oct 2020, at 10:21, ummeegge >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi Michael, >>>>>>>>>> >>>>>>>>>> Am Mittwoch, den 07.10.2020, 09:20 +0100 schrieb >>>>>>>>>> Michael >>>>>>>>>> Tremer: >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Oh so this is a custom thing? >>>>>>>>>>> >>>>>>>>>>> Obviously most users won=E2=80=99t use this. If you care much >>>>>>>>>>> about >>>>>>>>>>> your >>>>>>>>>>> custom script, you can write a script that searches a >>>>>>>>>>> directory >>>>>>>>>>> and >>>>>>>>>>> calls all scripts in it (like >>>>>>>>>>> /etc/init.d/networking/red.up/ >>>>>>>>>>> and >>>>>>>>>>> /etc/init.d/networking/red.down/). >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> OK, will give it a try. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Another great example how OpenVPN breaks running >>>>>>>>>>> installations. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yes, and there are comming some exiting new examples >>>>>>>>>> with the >>>>>>>>>> upcoming >>>>>>>>>> releases 8-| ... >>>>>>>>>> >>>>>>>>> >>>>>>>>> Like what? >>>>>>>>> >>>>>>>> >>>>>>>> e.g. this >>>>>>>> >>>>>>>> >>>>>> >>>>>> >> https://community.ipfire.org/t/openvpn-2-5-development-version/2173/2 >>>>>>>> or >>>>>>>> >>>>>>>> >>>>>> >>>>>> >> https://community.ipfire.org/t/openvpn-2-5-development-version/2173/8 >>>>>>>> checkout the deprecated options :-\ >>>>>>>> >>>>>>>>> -Michael >>>>>>>>> >>>>>>>>> >>>>>>>>>>> -Michael >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On 6 Oct 2020, at 14:26, ummeegge < >>>>>>>>>>>> ummeegge(a)ipfire.org> >>>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Am Dienstag, den 06.10.2020, 12:58 +0100 schrieb >>>>>>>>>>>> Michael >>>>>>>>>>>> Tremer: >>>>>>>>>>>> >>>>>>>>>>>>> Why do you have more than one client- >>>>>>>>>>>>> connnect/disconnect >>>>>>>>>>>>> script >>>>>>>>>>>>> in >>>>>>>>>>>>> your configuration? >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> In this case it is a email which will be fired if >>>>>>>>>>>> someone >>>>>>>>>>>> is >>>>>>>>>>>> (dis)connected but there are plenty of potential >>>>>>>>>>>> possibilities. >>>>>>>>>>>> This >>>>>>>>>>>> one is not specified for my use case but may for >>>>>>>>>>>> the >>>>>>>>>>>> OpenVPN >>>>>>>>>>>> scripting >>>>>>>>>>>> architecture in IPFire in general. >>>>>>>>>>>> >>>>>>>>>>>> Best, >>>>>>>>>>>> >>>>>>>>>>>> Erik >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> -Michael >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On 5 Oct 2020, at 16:59, ummeegge < >>>>>>>>>>>>>> ummeegge(a)ipfire.org> >>>>>>>>>>>>>> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>> am currently in testing scenario with the new >>>>>>>>>>>>>> OpenVPN- >>>>>>>>>>>>>> 2.5_rc2 >>>>>>>>>>>>>> and a >>>>>>>>>>>>>> additional --client-connect/--client-disconnect >>>>>>>>>>>>>> script. >>>>>>>>>>>>>> Since >>>>>>>>>>>>>> the >>>>>>>>>>>>>> release of OpenVPN metrics --> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>> >>>>>> >> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D708f2b7368cc8fbd= 54a06ca66337ebdcc26b58b4 >>>>>>>>>>>>>> the new OpenVPN version lined out that only one >>>>>>>>>>>>>> script >>>>>>>>>>>>>> will >>>>>>>>>>>>>> be >>>>>>>>>>>>>> executed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> openvpnserver[15373]: Multiple --client-connect >>>>>>>>>>>>>> scripts >>>>>>>>>>>>>> defined. The >>>>>>>>>>>>>> previously configured script is overridden. >>>>>>>>>>>>>> openvpnserver[15373]: Multiple --client- >>>>>>>>>>>>>> disconnect >>>>>>>>>>>>>> scripts >>>>>>>>>>>>>> defined. The previously configured script is >>>>>>>>>>>>>> overridden. >>>>>>>>>>>>>> >>>>>>>>>>>>>> so a question arises (beneath a lot=C2=B4s others >>>>>>>>>>>>>> which are >>>>>>>>>>>>>> here >>>>>>>>>>>>>> OT), >>>>>>>>>>>>>> should >>>>>>>>>>>>>> we make it possible to execute more then one -- >>>>>>>>>>>>>> (dis)connect >>>>>>>>>>>>>> script >>>>>>>>>>>>>> ? If >>>>>>>>>>>>>> so, are there may some ideas for this ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best, >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Erik >=20 --===============1259130399496215408==--