[centos][kolla-ansible][wallaby][vpnaas] I need Help
Hello. I try one last time to get some help, answers to my questions because I have been trying for 2 weeks to get the vpnaas service to work under Wallaby, without success. Still, I have no problem under Victoria with vpnaas. However, on my last installation which must work in September (to be used by students), without my understanding why, the horizon container of my centos (rocky) / kolla-ansible / victoria installation does not want to launch and I do not have no logs. So, can't use Victoria. I am trying Wallaby, everything works except vpnaas. My questions: how to get the logs of this hoorizon container which does not start (restart every 20 seconds)? how to know if it is a bug in wallaby with vpnaas? Really thank you if anyone can help me move forward. Franck
On Fri, Jul 16, 2021 at 9:36 AM Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr> wrote:
Hello.
Hello,
I try one last time to get some help, answers to my questions because I have been trying for 2 weeks to get the vpnaas service to work under Wallaby, without success. Still, I have no problem under Victoria with vpnaas. However, on my last installation which must work in September (to be used by students), without my understanding why, the horizon container of my centos (rocky) / kolla-ansible / victoria installation does not want to launch and I do not have no logs. So, can't use Victoria. I am trying Wallaby, everything works except vpnaas. My questions: how to get the logs of this hoorizon container which does not start (restart every 20 seconds)? how to know if it is a bug in wallaby with vpnaas? Really thank you if anyone can help me move forward.
I don't really have experience with Neutron VPNaaS. Is there anything more specific than "it doesn't work"? What's the behaviour in V and what's in W? Regarding Horizon - it is known to be working. Perhaps it's breaking due to some customisation. Did you check the docker logs on the Horizon container? They should contain a hint as to why the restart is happening. -yoctozepto
Thank you for your help. I explained in a first message last week the problem with vpnaas: Neutron-l3-agent logs says: Command: ['ipsec', 'whack', '--status'] Exit code: 33 Stdout: Stderr: whack: Pluto is not running (no "/run/pluto/pluto.ctl ») when I do the same things with Victoria (on a test lab, not on my student servers), no problem with vnaaas, no problem with horizon. On the servers for, I try Victoria. Problem with the horizon container, but no logs, I don't understand the problem (I never had a problem with horizon). The only thing that's new: Rocky instead of Centos (I don't know whether to use Stream or Rocky, it's tricky this story). How to find the horizon problem without logs? How to find the problem that prevents this container from starting (all the others are UP) Franck
Le 16 juil. 2021 à 09:46, Radosław Piliszek <radoslaw.piliszek@gmail.com> a écrit :
On Fri, Jul 16, 2021 at 9:36 AM Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr <mailto:franck.vedel@univ-grenoble-alpes.fr>> wrote:
Hello.
Hello,
I try one last time to get some help, answers to my questions because I have been trying for 2 weeks to get the vpnaas service to work under Wallaby, without success. Still, I have no problem under Victoria with vpnaas. However, on my last installation which must work in September (to be used by students), without my understanding why, the horizon container of my centos (rocky) / kolla-ansible / victoria installation does not want to launch and I do not have no logs. So, can't use Victoria. I am trying Wallaby, everything works except vpnaas. My questions: how to get the logs of this hoorizon container which does not start (restart every 20 seconds)? how to know if it is a bug in wallaby with vpnaas? Really thank you if anyone can help me move forward.
I don't really have experience with Neutron VPNaaS. Is there anything more specific than "it doesn't work"? What's the behaviour in V and what's in W?
Regarding Horizon - it is known to be working. Perhaps it's breaking due to some customisation. Did you check the docker logs on the Horizon container? They should contain a hint as to why the restart is happening.
-yoctozepto
On Fri, Jul 16, 2021 at 9:54 AM Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr> wrote:
Thank you for your help. I explained in a first message last week the problem with vpnaas:
Neutron-l3-agent logs says: Command: ['ipsec', 'whack', '--status'] Exit code: 33 Stdout: Stderr: whack: Pluto is not running (no "/run/pluto/pluto.ctl »)
That does not ring any bell in my head. There does not seem to be any relevant difference between V and W w.r.t VPNaaS.
when I do the same things with Victoria (on a test lab, not on my student servers), no problem with vnaaas, no problem with horizon. On the servers for, I try Victoria. Problem with the horizon container, but no logs, I don't understand the problem (I never had a problem with horizon). The only thing that's new: Rocky instead of Centos (I don't know whether to use Stream or Rocky, it's tricky this story). How to find the horizon problem without logs? How to find the problem that prevents this container from starting (all the others are UP)
We normally support only Stream but Rocky should probably still work as a host. Do you mean that doing `docker logs horizon` produces zero output? Like, totally nothing? That would be suspicious as we log quite a bit of preamble that is extremely unlikely to fail before the first message gets logged. Also try `docker inspect horizon` and attach its output, e.g., via https://paste.ubuntu.com/ -yoctozepto
i can't put results from docker inspect, right now, Wallaby is working, because Horizon is working. So as a first step I am trying to get vpnaas to work with Wallaby. For information, on a first test lab, the vpnaas service had to work the first time with Victoria. I had tried with Wallaby, and already it did not work for the same reasons as today (pluto). It was on Centos Stream (8.4 if I remember correctly). For my students i must have vpnaas working so i am willing to come back to victoria for this but since horizon is not launching i am .... stuck. Since I am doing the exact same things with V and W, I don't understand why it doesn't work unless there is a bug which is possible. LEFT RIGHT pings from the local network to the other local network go to the Internet No VPN between the 2 networks. do i come back to victoria or do i continue with wallaby n hoping to find the problem with your help? Franck
Le 16 juil. 2021 à 10:22, Radosław Piliszek <radoslaw.piliszek@gmail.com> a écrit :
On Fri, Jul 16, 2021 at 9:54 AM Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr> wrote:
Thank you for your help. I explained in a first message last week the problem with vpnaas:
Neutron-l3-agent logs says: Command: ['ipsec', 'whack', '--status'] Exit code: 33 Stdout: Stderr: whack: Pluto is not running (no "/run/pluto/pluto.ctl »)
That does not ring any bell in my head. There does not seem to be any relevant difference between V and W w.r.t VPNaaS.
when I do the same things with Victoria (on a test lab, not on my student servers), no problem with vnaaas, no problem with horizon. On the servers for, I try Victoria. Problem with the horizon container, but no logs, I don't understand the problem (I never had a problem with horizon). The only thing that's new: Rocky instead of Centos (I don't know whether to use Stream or Rocky, it's tricky this story). How to find the horizon problem without logs? How to find the problem that prevents this container from starting (all the others are UP)
We normally support only Stream but Rocky should probably still work as a host.
Do you mean that doing `docker logs horizon` produces zero output? Like, totally nothing? That would be suspicious as we log quite a bit of preamble that is extremely unlikely to fail before the first message gets logged. Also try `docker inspect horizon` and attach its output, e.g., via https://paste.ubuntu.com/
-yoctozepto
On Fri, Jul 16, 2021 at 10:38 AM Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr> wrote:
do i come back to victoria or do i continue with wallaby n hoping to find the problem with your help?
As I mentioned before, I can't help you with VPNaaS. I am not aware of the changes in Neutron between V and W that could break it. We can focus on V for now to get it working with Horizon. That is something I can relate to. For VPNaaS in Wallaby, I suggest you start a thread with [neutron] instead of [kolla-ansible] and explain that it stops working in W while it worked in V. -yoctozepto
Hello Having had no help with my Vpnaas (centos wallaby) problem, I came back to Victoria because I know from having tested that Vpnaas works as it should under Victoria. A few weeks ago, I had the opportunity to use 3 test servers, I had set up Victoria (with Centos and kolla-ansible). No problem, everything was working as I wanted it to. I have since set up 3 new servers to set up an Openstack for my students. if i install Wallaby, no Vpnaas, and I need VPNaaS…. So Victoria. if I install Victoria, and this is the 1st time that this happens to me, horizon does not work. The horizon docker does not start. The "docker logs horizon" command ends with the following 3 lines: ++ config_karbor_dashboard ++ for file in $ {SITE_PACKAGES} / karbor_dashboard / enabled / _ * [^ __]. py / usr / local / bin / kolla_extend_start: line 121: ENABLE_KARBOR: unbound variable I cannot understand the problem. Is it possible to have some help, some clues to solve this problem. Many thanks in advance. Franck VEDEL
Le 16 juil. 2021 à 11:19, Radosław Piliszek <radoslaw.piliszek@gmail.com> a écrit :
On Fri, Jul 16, 2021 at 10:38 AM Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr> wrote:
do i come back to victoria or do i continue with wallaby n hoping to find the problem with your help?
As I mentioned before, I can't help you with VPNaaS. I am not aware of the changes in Neutron between V and W that could break it. We can focus on V for now to get it working with Horizon. That is something I can relate to. For VPNaaS in Wallaby, I suggest you start a thread with [neutron] instead of [kolla-ansible] and explain that it stops working in W while it worked in V.
-yoctozepto
On Sun, Jul 25, 2021 at 2:52 PM Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr> wrote:
Hello
Hello Franck,
Having had no help with my Vpnaas (centos wallaby) problem, I came back to Victoria because I know from having tested that Vpnaas works as it should under Victoria. A few weeks ago, I had the opportunity to use 3 test servers, I had set up Victoria (with Centos and kolla-ansible). No problem, everything was working as I wanted it to. I have since set up 3 new servers to set up an Openstack for my students. if i install Wallaby, no Vpnaas, and I need VPNaaS…. So Victoria.
if I install Victoria, and this is the 1st time that this happens to me, horizon does not work. The horizon docker does not start. The "docker logs horizon" command ends with the following 3 lines: ++ config_karbor_dashboard ++ for file in $ {SITE_PACKAGES} / karbor_dashboard / enabled / _ * [^ __]. py / usr / local / bin / kolla_extend_start: line 121: ENABLE_KARBOR: unbound variable
This error suggests you are using Kolla Ansible Wallaby or later to deploy Victoria. You probably just set "openstack_release" to "Victoria" without downgrading Kolla Ansible to a supported version. There is a reason why "openstack_release" is commented with "Do not override this unless you know what you are doing.". ;-) It is only really meant to be used for very specific tasks, not really meant for regular users. Please have a look at https://docs.openstack.org/releasenotes/kolla-ansible/victoria.html The latest release for Victoria is 11.0.0 but there are lots of unreleased fixes so I advise you to just clone https://opendev.org/openstack/kolla-ansible checkout stable/victoria and pip install that directory then. It will fix your current issue. -yoctozepto
Oh !! Thanks a lot, really. Indeed, I installed kolla-ansible 12.0, install wallaby (it works perfectly… expect Vpnaas), then I changed "wallaby" to « victoria » in globals.yml. And in Wallaby's notes, there is the sentence: The Karbor project is no longer maintained and retired since the Wallaby cycle. Its support and roles are also removed since Wallaby cycle. So, it's not normal that it doesn't work. I understand…. There is a lot of things, it’s not easy to do the right thing the first time. On the other hand ... and I hope not to abuse, I am not sure I understand "clone https://opendev.org/openstack/kolla-ansible". Do you have to uninstall kolla-ansible 12 before putting 11? How do you do "pip install that directory then"? Really sorry for these stupid questions, but I'm afraid to mess things up. Franck
Le 25 juil. 2021 à 18:00, Radosław Piliszek <radoslaw.piliszek@gmail.com> a écrit :
On Sun, Jul 25, 2021 at 2:52 PM Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr <mailto:franck.vedel@univ-grenoble-alpes.fr>> wrote:
Hello
Hello Franck,
Having had no help with my Vpnaas (centos wallaby) problem, I came back to Victoria because I know from having tested that Vpnaas works as it should under Victoria. A few weeks ago, I had the opportunity to use 3 test servers, I had set up Victoria (with Centos and kolla-ansible). No problem, everything was working as I wanted it to. I have since set up 3 new servers to set up an Openstack for my students. if i install Wallaby, no Vpnaas, and I need VPNaaS…. So Victoria.
if I install Victoria, and this is the 1st time that this happens to me, horizon does not work. The horizon docker does not start. The "docker logs horizon" command ends with the following 3 lines: ++ config_karbor_dashboard ++ for file in $ {SITE_PACKAGES} / karbor_dashboard / enabled / _ * [^ __]. py / usr / local / bin / kolla_extend_start: line 121: ENABLE_KARBOR: unbound variable
This error suggests you are using Kolla Ansible Wallaby or later to deploy Victoria. You probably just set "openstack_release" to "Victoria" without downgrading Kolla Ansible to a supported version. There is a reason why "openstack_release" is commented with "Do not override this unless you know what you are doing.". ;-) It is only really meant to be used for very specific tasks, not really meant for regular users. Please have a look at https://docs.openstack.org/releasenotes/kolla-ansible/victoria.html <https://docs.openstack.org/releasenotes/kolla-ansible/victoria.html> The latest release for Victoria is 11.0.0 but there are lots of unreleased fixes so I advise you to just clone https://opendev.org/openstack/kolla-ansible <https://opendev.org/openstack/kolla-ansible> checkout stable/victoria and pip install that directory then. It will fix your current issue.
-yoctozepto
On Sun, Jul 25, 2021 at 9:18 PM Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr> wrote:
Oh !! Thanks a lot, really.
Indeed, I installed kolla-ansible 12.0, install wallaby (it works perfectly… expect Vpnaas), then I changed "wallaby" to « victoria » in globals.yml.
And in Wallaby's notes, there is the sentence: The Karbor project is no longer maintained and retired since the Wallaby cycle. Its support and roles are also removed since Wallaby cycle. So, it's not normal that it doesn't work. I understand…. There is a lot of things, it’s not easy to do the right thing the first time.
On the other hand ... and I hope not to abuse, I am not sure I understand "clone https://opendev.org/openstack/kolla-ansible". Do you have to uninstall kolla-ansible 12 before putting 11? How do you do "pip install that directory then"? Really sorry for these stupid questions, but I'm afraid to mess things up.
Sure thing. I meant to use Git. Try these commands: git clone --branch stable/victoria \ https://opendev.org/openstack/kolla-ansible pip install ./kolla-ansible -yoctozepto
Franck
Le 25 juil. 2021 à 18:00, Radosław Piliszek <radoslaw.piliszek@gmail.com> a écrit :
On Sun, Jul 25, 2021 at 2:52 PM Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr> wrote:
Hello
Hello Franck,
Having had no help with my Vpnaas (centos wallaby) problem, I came back to Victoria because I know from having tested that Vpnaas works as it should under Victoria. A few weeks ago, I had the opportunity to use 3 test servers, I had set up Victoria (with Centos and kolla-ansible). No problem, everything was working as I wanted it to. I have since set up 3 new servers to set up an Openstack for my students. if i install Wallaby, no Vpnaas, and I need VPNaaS…. So Victoria.
if I install Victoria, and this is the 1st time that this happens to me, horizon does not work. The horizon docker does not start. The "docker logs horizon" command ends with the following 3 lines: ++ config_karbor_dashboard ++ for file in $ {SITE_PACKAGES} / karbor_dashboard / enabled / _ * [^ __]. py / usr / local / bin / kolla_extend_start: line 121: ENABLE_KARBOR: unbound variable
This error suggests you are using Kolla Ansible Wallaby or later to deploy Victoria. You probably just set "openstack_release" to "Victoria" without downgrading Kolla Ansible to a supported version. There is a reason why "openstack_release" is commented with "Do not override this unless you know what you are doing.". ;-) It is only really meant to be used for very specific tasks, not really meant for regular users. Please have a look at https://docs.openstack.org/releasenotes/kolla-ansible/victoria.html The latest release for Victoria is 11.0.0 but there are lots of unreleased fixes so I advise you to just clone https://opendev.org/openstack/kolla-ansible checkout stable/victoria and pip install that directory then. It will fix your current issue.
-yoctozepto
awesome !! You have helped me so much! Thanks a lot. I had made the git clone, but not properly. It's really difficult to teach corporate IT without having some training. We need increasingly complex tools. good, I put back my configuration (https, ldap, haproxy, lvm and iscsi bay, quotas, images). Tomorrow: tests of the Vpnaas service. Thanks thanks thanks Franck
Le 25 juil. 2021 à 21:25, Radosław Piliszek <radoslaw.piliszek@gmail.com> a écrit :
On Sun, Jul 25, 2021 at 9:18 PM Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr <mailto:franck.vedel@univ-grenoble-alpes.fr>> wrote:
Oh !! Thanks a lot, really.
Indeed, I installed kolla-ansible 12.0, install wallaby (it works perfectly… expect Vpnaas), then I changed "wallaby" to « victoria » in globals.yml.
And in Wallaby's notes, there is the sentence: The Karbor project is no longer maintained and retired since the Wallaby cycle. Its support and roles are also removed since Wallaby cycle. So, it's not normal that it doesn't work. I understand…. There is a lot of things, it’s not easy to do the right thing the first time.
On the other hand ... and I hope not to abuse, I am not sure I understand "clone https://opendev.org/openstack/kolla-ansible". Do you have to uninstall kolla-ansible 12 before putting 11? How do you do "pip install that directory then"? Really sorry for these stupid questions, but I'm afraid to mess things up.
Sure thing. I meant to use Git. Try these commands:
git clone --branch stable/victoria \ https://opendev.org/openstack/kolla-ansible <https://opendev.org/openstack/kolla-ansible> pip install ./kolla-ansible
-yoctozepto
Franck
Le 25 juil. 2021 à 18:00, Radosław Piliszek <radoslaw.piliszek@gmail.com> a écrit :
On Sun, Jul 25, 2021 at 2:52 PM Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr> wrote:
Hello
Hello Franck,
Having had no help with my Vpnaas (centos wallaby) problem, I came back to Victoria because I know from having tested that Vpnaas works as it should under Victoria. A few weeks ago, I had the opportunity to use 3 test servers, I had set up Victoria (with Centos and kolla-ansible). No problem, everything was working as I wanted it to. I have since set up 3 new servers to set up an Openstack for my students. if i install Wallaby, no Vpnaas, and I need VPNaaS…. So Victoria.
if I install Victoria, and this is the 1st time that this happens to me, horizon does not work. The horizon docker does not start. The "docker logs horizon" command ends with the following 3 lines: ++ config_karbor_dashboard ++ for file in $ {SITE_PACKAGES} / karbor_dashboard / enabled / _ * [^ __]. py / usr / local / bin / kolla_extend_start: line 121: ENABLE_KARBOR: unbound variable
This error suggests you are using Kolla Ansible Wallaby or later to deploy Victoria. You probably just set "openstack_release" to "Victoria" without downgrading Kolla Ansible to a supported version. There is a reason why "openstack_release" is commented with "Do not override this unless you know what you are doing.". ;-) It is only really meant to be used for very specific tasks, not really meant for regular users. Please have a look at https://docs.openstack.org/releasenotes/kolla-ansible/victoria.html The latest release for Victoria is 11.0.0 but there are lots of unreleased fixes so I advise you to just clone https://opendev.org/openstack/kolla-ansible checkout stable/victoria and pip install that directory then. It will fix your current issue.
-yoctozepto
Hello. unfortunately, despite the good functioning of Victoria, the VPNAAS service is not working. Same error as for wallaby: Command: ['ipsec', 'whack', '--status'] Exit code: 33 Stdout: Stderr: whack: Pluto is not running (no "/run/pluto/pluto.ctl") ; Stderr: I think it's my fault. I didn't want to install CentOS Stream (not knowing what happened with this distribution), I put Rocky. This is a big mistake. I will start all over again, put CentOS Stream (VPNaas worked with Victoria and CentOS Stream in my tests). Thanks again. I'm still disgusted with all this wasted time. Franck
Le 25 juil. 2021 à 21:25, Radosław Piliszek <radoslaw.piliszek@gmail.com> a écrit :
On Sun, Jul 25, 2021 at 9:18 PM Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr <mailto:franck.vedel@univ-grenoble-alpes.fr>> wrote:
Oh !! Thanks a lot, really.
Indeed, I installed kolla-ansible 12.0, install wallaby (it works perfectly… expect Vpnaas), then I changed "wallaby" to « victoria » in globals.yml.
And in Wallaby's notes, there is the sentence: The Karbor project is no longer maintained and retired since the Wallaby cycle. Its support and roles are also removed since Wallaby cycle. So, it's not normal that it doesn't work. I understand…. There is a lot of things, it’s not easy to do the right thing the first time.
On the other hand ... and I hope not to abuse, I am not sure I understand "clone https://opendev.org/openstack/kolla-ansible". Do you have to uninstall kolla-ansible 12 before putting 11? How do you do "pip install that directory then"? Really sorry for these stupid questions, but I'm afraid to mess things up.
Sure thing. I meant to use Git. Try these commands:
git clone --branch stable/victoria \ https://opendev.org/openstack/kolla-ansible <https://opendev.org/openstack/kolla-ansible> pip install ./kolla-ansible
-yoctozepto
Franck
Le 25 juil. 2021 à 18:00, Radosław Piliszek <radoslaw.piliszek@gmail.com> a écrit :
On Sun, Jul 25, 2021 at 2:52 PM Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr> wrote:
Hello
Hello Franck,
Having had no help with my Vpnaas (centos wallaby) problem, I came back to Victoria because I know from having tested that Vpnaas works as it should under Victoria. A few weeks ago, I had the opportunity to use 3 test servers, I had set up Victoria (with Centos and kolla-ansible). No problem, everything was working as I wanted it to. I have since set up 3 new servers to set up an Openstack for my students. if i install Wallaby, no Vpnaas, and I need VPNaaS…. So Victoria.
if I install Victoria, and this is the 1st time that this happens to me, horizon does not work. The horizon docker does not start. The "docker logs horizon" command ends with the following 3 lines: ++ config_karbor_dashboard ++ for file in $ {SITE_PACKAGES} / karbor_dashboard / enabled / _ * [^ __]. py / usr / local / bin / kolla_extend_start: line 121: ENABLE_KARBOR: unbound variable
This error suggests you are using Kolla Ansible Wallaby or later to deploy Victoria. You probably just set "openstack_release" to "Victoria" without downgrading Kolla Ansible to a supported version. There is a reason why "openstack_release" is commented with "Do not override this unless you know what you are doing.". ;-) It is only really meant to be used for very specific tasks, not really meant for regular users. Please have a look at https://docs.openstack.org/releasenotes/kolla-ansible/victoria.html The latest release for Victoria is 11.0.0 but there are lots of unreleased fixes so I advise you to just clone https://opendev.org/openstack/kolla-ansible checkout stable/victoria and pip install that directory then. It will fix your current issue.
-yoctozepto
On Mon, Jul 26, 2021 at 10:39 AM Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr> wrote:
Hello. unfortunately, despite the good functioning of Victoria, the VPNAAS service is not working. Same error as for wallaby:
Command: ['ipsec', 'whack', '--status'] Exit code: 33 Stdout: Stderr: whack: Pluto is not running (no "/run/pluto/pluto.ctl") ; Stderr:
I think it's my fault. I didn't want to install CentOS Stream (not knowing what happened with this distribution), I put Rocky. This is a big mistake. I will start all over again, put CentOS Stream (VPNaas worked with Victoria and CentOS Stream in my tests). Thanks again. I'm still disgusted with all this wasted time.
Hello Franck, Before you go wrecking your infra - I am pretty sure that Rocky vs Stream does not make a difference here. I thought Victoria worked because you said so but it seems it has always broken in Kolla Ansible and we have a bug to fix: https://bugs.launchpad.net/kolla-ansible/+bug/1869491 VPNaaS is not the most popular enabled option to be honest. Do you remember how you got it working back then? That could help here. -yoctozepto
Franck
Le 25 juil. 2021 à 21:25, Radosław Piliszek <radoslaw.piliszek@gmail.com> a écrit :
On Sun, Jul 25, 2021 at 9:18 PM Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr> wrote:
Oh !! Thanks a lot, really.
Indeed, I installed kolla-ansible 12.0, install wallaby (it works perfectly… expect Vpnaas), then I changed "wallaby" to « victoria » in globals.yml.
And in Wallaby's notes, there is the sentence: The Karbor project is no longer maintained and retired since the Wallaby cycle. Its support and roles are also removed since Wallaby cycle. So, it's not normal that it doesn't work. I understand…. There is a lot of things, it’s not easy to do the right thing the first time.
On the other hand ... and I hope not to abuse, I am not sure I understand "clone https://opendev.org/openstack/kolla-ansible". Do you have to uninstall kolla-ansible 12 before putting 11? How do you do "pip install that directory then"? Really sorry for these stupid questions, but I'm afraid to mess things up.
Sure thing. I meant to use Git. Try these commands:
git clone --branch stable/victoria \ https://opendev.org/openstack/kolla-ansible pip install ./kolla-ansible
-yoctozepto
Franck
Le 25 juil. 2021 à 18:00, Radosław Piliszek <radoslaw.piliszek@gmail.com> a écrit :
On Sun, Jul 25, 2021 at 2:52 PM Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr> wrote:
Hello
Hello Franck,
Having had no help with my Vpnaas (centos wallaby) problem, I came back to Victoria because I know from having tested that Vpnaas works as it should under Victoria. A few weeks ago, I had the opportunity to use 3 test servers, I had set up Victoria (with Centos and kolla-ansible). No problem, everything was working as I wanted it to. I have since set up 3 new servers to set up an Openstack for my students. if i install Wallaby, no Vpnaas, and I need VPNaaS…. So Victoria.
if I install Victoria, and this is the 1st time that this happens to me, horizon does not work. The horizon docker does not start. The "docker logs horizon" command ends with the following 3 lines: ++ config_karbor_dashboard ++ for file in $ {SITE_PACKAGES} / karbor_dashboard / enabled / _ * [^ __]. py / usr / local / bin / kolla_extend_start: line 121: ENABLE_KARBOR: unbound variable
This error suggests you are using Kolla Ansible Wallaby or later to deploy Victoria. You probably just set "openstack_release" to "Victoria" without downgrading Kolla Ansible to a supported version. There is a reason why "openstack_release" is commented with "Do not override this unless you know what you are doing.". ;-) It is only really meant to be used for very specific tasks, not really meant for regular users. Please have a look at https://docs.openstack.org/releasenotes/kolla-ansible/victoria.html The latest release for Victoria is 11.0.0 but there are lots of unreleased fixes so I advise you to just clone https://opendev.org/openstack/kolla-ansible checkout stable/victoria and pip install that directory then. It will fix your current issue.
-yoctozepto
Hello, I didn't check Rocky or Stream for differences, but if I recap the problem correctly: - Neither Victoria nor Wallaby VPNaaS worked in Stream. - Victoria worked in Rocky There are no relevant differences in the VPNaaS plugin between Victoria and Wallaby. Maybe there actually is a difference between Rocky and Stream: the pid directory expected by pluto. At least your error message (no "/run/pluto/pluto.ctl") suggests that. The libreswan driver in the VPNaaS plugin works under the assumption that the run-files reside in /var/run. ipsec commands are run via a wrapper to call the actual command inside a namespace, with /etc/ and /var/run/ bind-mounted. The real paths are /var/lib/neutron/ipsec/{router-id}/... and in there .../etc and ..,/var/run. In a working setup you should find /var/lib/neutron/ipsec/{router-id}/var/run/pluto/pluto.ctl So it may be a problem if pluto wants to use /run (not bind-mounted), but the plugin only provides for /var/run (bind-mounted). Bodo Petermann SysEleven GmbH
Am 26.07.2021 um 15:12 schrieb Radosław Piliszek <radoslaw.piliszek@gmail.com>:
On Mon, Jul 26, 2021 at 10:39 AM Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr <mailto:franck.vedel@univ-grenoble-alpes.fr>> wrote:
Hello. unfortunately, despite the good functioning of Victoria, the VPNAAS service is not working. Same error as for wallaby:
Command: ['ipsec', 'whack', '--status'] Exit code: 33 Stdout: Stderr: whack: Pluto is not running (no "/run/pluto/pluto.ctl") ; Stderr:
I think it's my fault. I didn't want to install CentOS Stream (not knowing what happened with this distribution), I put Rocky. This is a big mistake. I will start all over again, put CentOS Stream (VPNaas worked with Victoria and CentOS Stream in my tests). Thanks again. I'm still disgusted with all this wasted time.
Hello Franck,
Before you go wrecking your infra - I am pretty sure that Rocky vs Stream does not make a difference here. I thought Victoria worked because you said so but it seems it has always broken in Kolla Ansible and we have a bug to fix: https://bugs.launchpad.net/kolla-ansible/+bug/1869491 <https://bugs.launchpad.net/kolla-ansible/+bug/1869491> VPNaaS is not the most popular enabled option to be honest.
Do you remember how you got it working back then? That could help here.
-yoctozepto
Franck
Le 25 juil. 2021 à 21:25, Radosław Piliszek <radoslaw.piliszek@gmail.com> a écrit :
On Sun, Jul 25, 2021 at 9:18 PM Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr> wrote:
Oh !! Thanks a lot, really.
Indeed, I installed kolla-ansible 12.0, install wallaby (it works perfectly… expect Vpnaas), then I changed "wallaby" to « victoria » in globals.yml.
And in Wallaby's notes, there is the sentence: The Karbor project is no longer maintained and retired since the Wallaby cycle. Its support and roles are also removed since Wallaby cycle. So, it's not normal that it doesn't work. I understand…. There is a lot of things, it’s not easy to do the right thing the first time.
On the other hand ... and I hope not to abuse, I am not sure I understand "clone https://opendev.org/openstack/kolla-ansible". Do you have to uninstall kolla-ansible 12 before putting 11? How do you do "pip install that directory then"? Really sorry for these stupid questions, but I'm afraid to mess things up.
Sure thing. I meant to use Git. Try these commands:
git clone --branch stable/victoria \ https://opendev.org/openstack/kolla-ansible pip install ./kolla-ansible
-yoctozepto
Franck
Le 25 juil. 2021 à 18:00, Radosław Piliszek <radoslaw.piliszek@gmail.com> a écrit :
On Sun, Jul 25, 2021 at 2:52 PM Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr> wrote:
Hello
Hello Franck,
Having had no help with my Vpnaas (centos wallaby) problem, I came back to Victoria because I know from having tested that Vpnaas works as it should under Victoria. A few weeks ago, I had the opportunity to use 3 test servers, I had set up Victoria (with Centos and kolla-ansible). No problem, everything was working as I wanted it to. I have since set up 3 new servers to set up an Openstack for my students. if i install Wallaby, no Vpnaas, and I need VPNaaS…. So Victoria.
if I install Victoria, and this is the 1st time that this happens to me, horizon does not work. The horizon docker does not start. The "docker logs horizon" command ends with the following 3 lines: ++ config_karbor_dashboard ++ for file in $ {SITE_PACKAGES} / karbor_dashboard / enabled / _ * [^ __]. py / usr / local / bin / kolla_extend_start: line 121: ENABLE_KARBOR: unbound variable
This error suggests you are using Kolla Ansible Wallaby or later to deploy Victoria. You probably just set "openstack_release" to "Victoria" without downgrading Kolla Ansible to a supported version. There is a reason why "openstack_release" is commented with "Do not override this unless you know what you are doing.". ;-) It is only really meant to be used for very specific tasks, not really meant for regular users. Please have a look at https://docs.openstack.org/releasenotes/kolla-ansible/victoria.html The latest release for Victoria is 11.0.0 but there are lots of unreleased fixes so I advise you to just clone https://opendev.org/openstack/kolla-ansible checkout stable/victoria and pip install that directory then. It will fix your current issue.
-yoctozepto
Hello Bodo, hello Radoslaw, thanks a lot for your help. My situation is: In June: 3 test servers. CentOS Stream (8.4). Victoria + Vpnaas: OK Wallaby + Vpnaas: NOT OK In July: 3 new (different) servers: Rocky OS (8.4) (I changed /etc/system.release to install Openstack) Wallaby + Vpnaas: NOT OK (1), all is working except VPNaaS Victoria + Vpnaas: NOT OK (2), all is working except VPNaaS (thanks Radoslaw for horizon !!) Error messages for 1): Neutron-l3-agent logs says: Command: ['ipsec', 'whack', '--status'] Exit code: 33 Stdout: Stderr: whack: Pluto is not running (no "/run/pluto/pluto.ctl ») 2): More complete 2021-07-26 20:24:23.352 34 ERROR neutron.agent.linux.utils [-] Exit code: 33; Cmd: ['sudo', 'neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'netns', 'exec', 'qrouter-a63770d5-edad-425d-8330-7d12c2cbf3e4', '/var/lib/kolla/venv/bin/neutron-vpn-netns-wrapper', '--mount_paths=/etc:/var/lib/neutron/ipsec/a63770d5-edad-425d-8330-7d12c2cbf3e4/etc,/var/run:/var/lib/neutron/ipsec/a63770d5-edad-425d-8330-7d12c2cbf3e4/var/run', '--rootwrap_config=/etc/neutron/rootwrap.conf', '--cmd=ipsec,whack,--status']; Stdin: ; Stdout: 2021-07-26 20:24:23.163 39401 INFO neutron.common.config [-] Logging enabled! 2021-07-26 20:24:23.164 39401 INFO neutron.common.config [-] /var/lib/kolla/venv/bin/neutron-vpn-netns-wrapper version 17.1.3.dev54 Command: ['mount', '--bind', '/var/lib/neutron/ipsec/a63770d5-edad-425d-8330-7d12c2cbf3e4/etc', '/etc'] Exit code: 0 Stdout: Stderr: 2021-07-26 20:24:23.186 39401 INFO neutron_vpnaas.services.vpn.common.netns_wrapper [-] /var/lib/neutron/ipsec/a63770d5-edad-425d-8330-7d12c2cbf3e4/etc has been bind-mounted in /etc Command: ['mount', '--bind', '/var/lib/neutron/ipsec/a63770d5-edad-425d-8330-7d12c2cbf3e4/var/run', '/var/run'] Exit code: 0 Stdout: Stderr: 2021-07-26 20:24:23.195 39401 INFO neutron_vpnaas.services.vpn.common.netns_wrapper [-] /var/lib/neutron/ipsec/a63770d5-edad-425d-8330-7d12c2cbf3e4/var/run has been bind-mounted in /var/run Command: ['ipsec', 'whack', '--status'] Exit code: 33 Stdout: Stderr: whack: Pluto is not running (no "/run/pluto/pluto.ctl") So… I tried what you say: « docker exec -it /bin/bash » « ps aux |grep pluto » ———> no pluto running You could also check if the configuration has been created properly: /var/lib/neutron/ipsec/{router-id}/etc with ipsec.conf and ipsec.secrets Yes, configuration is created (i think…..) [neutron@iut1r-srv-ops01-i01 /var/lib/neutron/ipsec/a63770d5-edad-425d-8330-7d12c2cbf3e4/etc]$ ls -l total 8 -rw-r--r--. 1 neutron neutron 0 Jul 26 09:49 hosts -rw-r--r--. 1 neutron neutron 1948 Jul 26 09:49 ipsec.conf drwxr-xr-x. 11 neutron neutron 135 Jul 26 09:49 ipsec.d -rw-------. 1 root root 107 Jul 26 09:49 ipsec.secrets drwxr-xr-x. 3 neutron neutron 19 Jul 26 09:49 pki -rw-r--r--. 1 neutron neutron 0 Jul 26 09:49 resolv.conf for exemple, the file /var/lib/neutron/ipsec/a63770d5-edad-425d-8330-7d12c2cbf3e4/etc/ipsec.conf is # Configuration for 2a1446f5-4618-4927-883a-7a8b702e13c1 config setup nat_traversal=yes virtual_private=%v4:10.0.1.0/24,%v4:10.0.2.0/24 conn %default keylife=60m keyingtries=%forever conn 6b588921-a120-402a-bed2-38c55879a432 # NOTE: a default route is required for %defaultroute to work... leftnexthop=%defaultroute rightnexthop=%defaultroute left=172.16.203.154 leftid=172.16.203.154 auto=start # NOTE:REQUIRED # [subnet] leftsubnet=10.0.1.0/24 # [updown] # What "updown" script to run to adjust routing and/or firewalling when # the status of the connection changes (default "ipsec _updown"). # "--route yes" allows to specify such routing options as mtu and metric. leftupdown="ipsec _updown --route yes" ###################### # ipsec_site_connections ###################### # [peer_address] right=172.16.201.79 # [peer_id] rightid=172.16.201.79 # [peer_cidrs] rightsubnets={ 10.0.2.0/24 } # rightsubnet=networkA/netmaskA, networkB/netmaskB (IKEv2 only) # [mtu] mtu=1500 # [dpd_action] dpdaction=hold # [dpd_interval] dpddelay=30 # [dpd_timeout] dpdtimeout=120 # [auth_mode] authby=secret ###################### # IKEPolicy params ###################### #ike version ikev2=never # [encryption_algorithm]-[auth_algorithm]-[pfs] ike=aes128-sha1;modp1536 # [lifetime_value] ikelifetime=3600s # NOTE: it looks lifetime_units=kilobytes can't be enforced (could be seconds, hours, days...) ########################## # IPsecPolicys params ########################## # [transform_protocol] phase2=esp # [encryption_algorithm]-[auth_algorithm]-[pfs] phase2alg=aes128-sha1;modp1536 # [encapsulation_mode] type=tunnel # [lifetime_value] lifetime=3600s # lifebytes=100000 if lifetime_units=kilobytes (IKEv2 only) ... I don’t know if you could see something wrong… but it is really very nice to help me with this problem. Franck
There are no relevant differences in the VPNaaS plugin between Victoria and Wallaby. Maybe there actually is a difference between Rocky and Stream: the pid directory expected by pluto. At least your error message (no "/run/pluto/pluto.ctl") suggests that. The libreswan driver in the VPNaaS plugin works under the assumption that the run-files reside in /var/run. ipsec commands are run via a wrapper to call the actual command inside a namespace, with /etc/ and /var/run/ bind-mounted.
The real paths are /var/lib/neutron/ipsec/{router-id}/... and in there .../etc and ..,/var/run. In a working setup you should find /var/lib/neutron/ipsec/{router-id}/var/run/pluto/pluto.ctl
So it may be a problem if pluto wants to use /run (not bind-mounted), but the plugin only provides for /var/run (bind-mounted).
Bodo Petermann SysEleven GmbH
Am 26.07.2021 um 15:12 schrieb Radosław Piliszek <radoslaw.piliszek@gmail.com <mailto:radoslaw.piliszek@gmail.com>>:
On Mon, Jul 26, 2021 at 10:39 AM Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr <mailto:franck.vedel@univ-grenoble-alpes.fr>> wrote:
Hello. unfortunately, despite the good functioning of Victoria, the VPNAAS service is not working. Same error as for wallaby:
Command: ['ipsec', 'whack', '--status'] Exit code: 33 Stdout: Stderr: whack: Pluto is not running (no "/run/pluto/pluto.ctl") ; Stderr:
I think it's my fault. I didn't want to install CentOS Stream (not knowing what happened with this distribution), I put Rocky. This is a big mistake. I will start all over again, put CentOS Stream (VPNaas worked with Victoria and CentOS Stream in my tests). Thanks again. I'm still disgusted with all this wasted time.
Hello Franck,
Before you go wrecking your infra - I am pretty sure that Rocky vs Stream does not make a difference here. I thought Victoria worked because you said so but it seems it has always broken in Kolla Ansible and we have a bug to fix: https://bugs.launchpad.net/kolla-ansible/+bug/1869491 <https://bugs.launchpad.net/kolla-ansible/+bug/1869491> VPNaaS is not the most popular enabled option to be honest.
Do you remember how you got it working back then? That could help here.
-yoctozepto
Franck
Le 25 juil. 2021 à 21:25, Radosław Piliszek <radoslaw.piliszek@gmail.com <mailto:radoslaw.piliszek@gmail.com>> a écrit :
On Sun, Jul 25, 2021 at 9:18 PM Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr <mailto:franck.vedel@univ-grenoble-alpes.fr>> wrote:
Oh !! Thanks a lot, really.
Indeed, I installed kolla-ansible 12.0, install wallaby (it works perfectly… expect Vpnaas), then I changed "wallaby" to « victoria » in globals.yml.
And in Wallaby's notes, there is the sentence: The Karbor project is no longer maintained and retired since the Wallaby cycle. Its support and roles are also removed since Wallaby cycle. So, it's not normal that it doesn't work. I understand…. There is a lot of things, it’s not easy to do the right thing the first time.
On the other hand ... and I hope not to abuse, I am not sure I understand "clone https://opendev.org/openstack/kolla-ansible <https://opendev.org/openstack/kolla-ansible>". Do you have to uninstall kolla-ansible 12 before putting 11? How do you do "pip install that directory then"? Really sorry for these stupid questions, but I'm afraid to mess things up.
Sure thing. I meant to use Git. Try these commands:
git clone --branch stable/victoria \ https://opendev.org/openstack/kolla-ansible <https://opendev.org/openstack/kolla-ansible> pip install ./kolla-ansible
-yoctozepto
Franck
Le 25 juil. 2021 à 18:00, Radosław Piliszek <radoslaw.piliszek@gmail.com <mailto:radoslaw.piliszek@gmail.com>> a écrit :
On Sun, Jul 25, 2021 at 2:52 PM Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr <mailto:franck.vedel@univ-grenoble-alpes.fr>> wrote:
Hello
Hello Franck,
Having had no help with my Vpnaas (centos wallaby) problem, I came back to Victoria because I know from having tested that Vpnaas works as it should under Victoria. A few weeks ago, I had the opportunity to use 3 test servers, I had set up Victoria (with Centos and kolla-ansible). No problem, everything was working as I wanted it to. I have since set up 3 new servers to set up an Openstack for my students. if i install Wallaby, no Vpnaas, and I need VPNaaS…. So Victoria.
if I install Victoria, and this is the 1st time that this happens to me, horizon does not work. The horizon docker does not start. The "docker logs horizon" command ends with the following 3 lines: ++ config_karbor_dashboard ++ for file in $ {SITE_PACKAGES} / karbor_dashboard / enabled / _ * [^ __]. py / usr / local / bin / kolla_extend_start: line 121: ENABLE_KARBOR: unbound variable
This error suggests you are using Kolla Ansible Wallaby or later to deploy Victoria. You probably just set "openstack_release" to "Victoria" without downgrading Kolla Ansible to a supported version. There is a reason why "openstack_release" is commented with "Do not override this unless you know what you are doing.". ;-) It is only really meant to be used for very specific tasks, not really meant for regular users. Please have a look at https://docs.openstack.org/releasenotes/kolla-ansible/victoria.html <https://docs.openstack.org/releasenotes/kolla-ansible/victoria.html> The latest release for Victoria is 11.0.0 but there are lots of unreleased fixes so I advise you to just clone https://opendev.org/openstack/kolla-ansible checkout stable/victoria and pip install that directory then. It will fix your current issue.
-yoctozepto
Hello Franck, I tried the ipsec pluto command the vpnaas plugin will use to start pluto on a CentOS 8 with libreswan 4.4 and the command fails: ipsec pluto --use-netkey --uniqueids /usr/libexec/ipsec/pluto: unrecognized option '--use-netkey' For usage information: /usr/libexec/ipsec/pluto --help Libreswan 4.4 That means that the vpnaas plugin is not up-to-date I'm afraid. Since libreswan 4.0 the option "--use-netkey" is called "--use-xfrm". The failing pluto command explains the error you copied: "Pluto is not running", but there should also be error messages about the failing ipsec pluto command. I don't know how it could have worked with Victoria and Stream though. Maybe there was an older libreswan? v3.32 might still work as it accepts the "--use-netkey" option. Unfortunately the ipsec pluto command issued by the plugin can only be fixed in the plugin itself, not by configuration. The only workaround I see for now is to try installing libreswan 3.32. Or switch to strongswan if that is available for CentOS. Regards Bodo
Am 26.07.2021 um 20:54 schrieb Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr>:
Hello Bodo, hello Radoslaw, thanks a lot for your help. My situation is: In June: 3 test servers. CentOS Stream (8.4). Victoria + Vpnaas: OK Wallaby + Vpnaas: NOT OK
In July: 3 new (different) servers: Rocky OS (8.4) (I changed /etc/system.release to install Openstack) Wallaby + Vpnaas: NOT OK (1), all is working except VPNaaS Victoria + Vpnaas: NOT OK (2), all is working except VPNaaS (thanks Radoslaw for horizon !!)
Error messages for 1): Neutron-l3-agent logs says: Command: ['ipsec', 'whack', '--status'] Exit code: 33 Stdout: Stderr: whack: Pluto is not running (no "/run/pluto/pluto.ctl »)
2): More complete 2021-07-26 20:24:23.352 34 ERROR neutron.agent.linux.utils [-] Exit code: 33; Cmd: ['sudo', 'neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'netns', 'exec', 'qrouter-a63770d5-edad-425d-8330-7d12c2cbf3e4', '/var/lib/kolla/venv/bin/neutron-vpn-netns-wrapper', '--mount_paths=/etc:/var/lib/neutron/ipsec/a63770d5-edad-425d-8330-7d12c2cbf3e4/etc,/var/run:/var/lib/neutron/ipsec/a63770d5-edad-425d-8330-7d12c2cbf3e4/var/run', '--rootwrap_config=/etc/neutron/rootwrap.conf', '--cmd=ipsec,whack,--status']; Stdin: ; Stdout: 2021-07-26 20:24:23.163 39401 INFO neutron.common.config [-] Logging enabled! 2021-07-26 20:24:23.164 39401 INFO neutron.common.config [-] /var/lib/kolla/venv/bin/neutron-vpn-netns-wrapper version 17.1.3.dev54 Command: ['mount', '--bind', '/var/lib/neutron/ipsec/a63770d5-edad-425d-8330-7d12c2cbf3e4/etc', '/etc'] Exit code: 0 Stdout: Stderr: 2021-07-26 20:24:23.186 39401 INFO neutron_vpnaas.services.vpn.common.netns_wrapper [-] /var/lib/neutron/ipsec/a63770d5-edad-425d-8330-7d12c2cbf3e4/etc has been bind-mounted in /etc Command: ['mount', '--bind', '/var/lib/neutron/ipsec/a63770d5-edad-425d-8330-7d12c2cbf3e4/var/run', '/var/run'] Exit code: 0 Stdout: Stderr: 2021-07-26 20:24:23.195 39401 INFO neutron_vpnaas.services.vpn.common.netns_wrapper [-] /var/lib/neutron/ipsec/a63770d5-edad-425d-8330-7d12c2cbf3e4/var/run has been bind-mounted in /var/run Command: ['ipsec', 'whack', '--status'] Exit code: 33 Stdout: Stderr: whack: Pluto is not running (no "/run/pluto/pluto.ctl")
So… I tried what you say: « docker exec -it /bin/bash » « ps aux |grep pluto » ———> no pluto running
You could also check if the configuration has been created properly: /var/lib/neutron/ipsec/{router-id}/etc with ipsec.conf and ipsec.secrets
Yes, configuration is created (i think…..) [neutron@iut1r-srv-ops01-i01 /var/lib/neutron/ipsec/a63770d5-edad-425d-8330-7d12c2cbf3e4/etc]$ ls -l total 8 -rw-r--r--. 1 neutron neutron 0 Jul 26 09:49 hosts -rw-r--r--. 1 neutron neutron 1948 Jul 26 09:49 ipsec.conf drwxr-xr-x. 11 neutron neutron 135 Jul 26 09:49 ipsec.d -rw-------. 1 root root 107 Jul 26 09:49 ipsec.secrets drwxr-xr-x. 3 neutron neutron 19 Jul 26 09:49 pki -rw-r--r--. 1 neutron neutron 0 Jul 26 09:49 resolv.conf
for exemple, the file /var/lib/neutron/ipsec/a63770d5-edad-425d-8330-7d12c2cbf3e4/etc/ipsec.conf is
# Configuration for 2a1446f5-4618-4927-883a-7a8b702e13c1 config setup nat_traversal=yes virtual_private=%v4:10.0.1.0/24,%v4:10.0.2.0/24 conn %default keylife=60m keyingtries=%forever conn 6b588921-a120-402a-bed2-38c55879a432 # NOTE: a default route is required for %defaultroute to work... leftnexthop=%defaultroute rightnexthop=%defaultroute left=172.16.203.154 leftid=172.16.203.154 auto=start # NOTE:REQUIRED # [subnet] leftsubnet=10.0.1.0/24 # [updown] # What "updown" script to run to adjust routing and/or firewalling when # the status of the connection changes (default "ipsec _updown"). # "--route yes" allows to specify such routing options as mtu and metric. leftupdown="ipsec _updown --route yes" ###################### # ipsec_site_connections ###################### # [peer_address] right=172.16.201.79 # [peer_id] rightid=172.16.201.79 # [peer_cidrs] rightsubnets={ 10.0.2.0/24 } # rightsubnet=networkA/netmaskA, networkB/netmaskB (IKEv2 only) # [mtu] mtu=1500 # [dpd_action] dpdaction=hold # [dpd_interval] dpddelay=30 # [dpd_timeout] dpdtimeout=120 # [auth_mode] authby=secret ###################### # IKEPolicy params ###################### #ike version ikev2=never # [encryption_algorithm]-[auth_algorithm]-[pfs] ike=aes128-sha1;modp1536 # [lifetime_value] ikelifetime=3600s # NOTE: it looks lifetime_units=kilobytes can't be enforced (could be seconds, hours, days...) ########################## # IPsecPolicys params ########################## # [transform_protocol] phase2=esp # [encryption_algorithm]-[auth_algorithm]-[pfs] phase2alg=aes128-sha1;modp1536 # [encapsulation_mode] type=tunnel # [lifetime_value] lifetime=3600s # lifebytes=100000 if lifetime_units=kilobytes (IKEv2 only) ... I don’t know if you could see something wrong… but it is really very nice to help me with this problem.
Franck
There are no relevant differences in the VPNaaS plugin between Victoria and Wallaby. Maybe there actually is a difference between Rocky and Stream: the pid directory expected by pluto. At least your error message (no "/run/pluto/pluto.ctl") suggests that. The libreswan driver in the VPNaaS plugin works under the assumption that the run-files reside in /var/run. ipsec commands are run via a wrapper to call the actual command inside a namespace, with /etc/ and /var/run/ bind-mounted.
The real paths are /var/lib/neutron/ipsec/{router-id}/... and in there .../etc and ..,/var/run. In a working setup you should find /var/lib/neutron/ipsec/{router-id}/var/run/pluto/pluto.ctl
So it may be a problem if pluto wants to use /run (not bind-mounted), but the plugin only provides for /var/run (bind-mounted).
Bodo Petermann SysEleven GmbH
Am 26.07.2021 um 15:12 schrieb Radosław Piliszek <radoslaw.piliszek@gmail.com <mailto:radoslaw.piliszek@gmail.com>>:
On Mon, Jul 26, 2021 at 10:39 AM Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr <mailto:franck.vedel@univ-grenoble-alpes.fr>> wrote:
Hello. unfortunately, despite the good functioning of Victoria, the VPNAAS service is not working. Same error as for wallaby:
Command: ['ipsec', 'whack', '--status'] Exit code: 33 Stdout: Stderr: whack: Pluto is not running (no "/run/pluto/pluto.ctl") ; Stderr:
I think it's my fault. I didn't want to install CentOS Stream (not knowing what happened with this distribution), I put Rocky. This is a big mistake. I will start all over again, put CentOS Stream (VPNaas worked with Victoria and CentOS Stream in my tests). Thanks again. I'm still disgusted with all this wasted time.
Hello Franck,
Before you go wrecking your infra - I am pretty sure that Rocky vs Stream does not make a difference here. I thought Victoria worked because you said so but it seems it has always broken in Kolla Ansible and we have a bug to fix: https://bugs.launchpad.net/kolla-ansible/+bug/1869491 <https://bugs.launchpad.net/kolla-ansible/+bug/1869491> VPNaaS is not the most popular enabled option to be honest.
Do you remember how you got it working back then? That could help here.
-yoctozepto
Franck
Le 25 juil. 2021 à 21:25, Radosław Piliszek <radoslaw.piliszek@gmail.com <mailto:radoslaw.piliszek@gmail.com>> a écrit :
On Sun, Jul 25, 2021 at 9:18 PM Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr <mailto:franck.vedel@univ-grenoble-alpes.fr>> wrote:
Oh !! Thanks a lot, really.
Indeed, I installed kolla-ansible 12.0, install wallaby (it works perfectly… expect Vpnaas), then I changed "wallaby" to « victoria » in globals.yml.
And in Wallaby's notes, there is the sentence: The Karbor project is no longer maintained and retired since the Wallaby cycle. Its support and roles are also removed since Wallaby cycle. So, it's not normal that it doesn't work. I understand…. There is a lot of things, it’s not easy to do the right thing the first time.
On the other hand ... and I hope not to abuse, I am not sure I understand "clone https://opendev.org/openstack/kolla-ansible <https://opendev.org/openstack/kolla-ansible>". Do you have to uninstall kolla-ansible 12 before putting 11? How do you do "pip install that directory then"? Really sorry for these stupid questions, but I'm afraid to mess things up.
Sure thing. I meant to use Git. Try these commands:
git clone --branch stable/victoria \ https://opendev.org/openstack/kolla-ansible <https://opendev.org/openstack/kolla-ansible> pip install ./kolla-ansible
-yoctozepto
Franck
Le 25 juil. 2021 à 18:00, Radosław Piliszek <radoslaw.piliszek@gmail.com <mailto:radoslaw.piliszek@gmail.com>> a écrit :
On Sun, Jul 25, 2021 at 2:52 PM Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr <mailto:franck.vedel@univ-grenoble-alpes.fr>> wrote:
Hello
Hello Franck,
Having had no help with my Vpnaas (centos wallaby) problem, I came back to Victoria because I know from having tested that Vpnaas works as it should under Victoria. A few weeks ago, I had the opportunity to use 3 test servers, I had set up Victoria (with Centos and kolla-ansible). No problem, everything was working as I wanted it to. I have since set up 3 new servers to set up an Openstack for my students. if i install Wallaby, no Vpnaas, and I need VPNaaS…. So Victoria.
if I install Victoria, and this is the 1st time that this happens to me, horizon does not work. The horizon docker does not start. The "docker logs horizon" command ends with the following 3 lines: ++ config_karbor_dashboard ++ for file in $ {SITE_PACKAGES} / karbor_dashboard / enabled / _ * [^ __]. py / usr / local / bin / kolla_extend_start: line 121: ENABLE_KARBOR: unbound variable
This error suggests you are using Kolla Ansible Wallaby or later to deploy Victoria. You probably just set "openstack_release" to "Victoria" without downgrading Kolla Ansible to a supported version. There is a reason why "openstack_release" is commented with "Do not override this unless you know what you are doing.". ;-) It is only really meant to be used for very specific tasks, not really meant for regular users. Please have a look at https://docs.openstack.org/releasenotes/kolla-ansible/victoria.html <https://docs.openstack.org/releasenotes/kolla-ansible/victoria.html> The latest release for Victoria is 11.0.0 but there are lots of unreleased fixes so I advise you to just clone https://opendev.org/openstack/kolla-ansible <https://opendev.org/openstack/kolla-ansible> checkout stable/victoria and pip install that directory then. It will fix your current issue.
-yoctozepto
Hello Bodo. Thanks a lot for this work. Before doing a lot off mistakes…. Impossible to start my test servers (with CentOS stream , Victoria, and Vpnaas working (I’m sure what it was working)), i’m on holidays…. So I start an VM with CentOS stream (installed with the same ISO file). Libreswan is 4.4. OK…. i try do downgrade with dnf…. Libreswan is ….. 4.3.3….. so same problem. I remove Libreswan, download https://download.libreswan.org/binaries/rhel/8/x86_64/libreswan-3.32-1.el8.x... <https://download.libreswan.org/binaries/rhel/8/x86_64/libreswan-3.32-1.el8.x86_64.rpm> and install it. Now, on my VM: ipsec pluto —help ——> -use-netkey is present…. like you say !! Maybe it’s the simple solution. So, what do you think if i do that: my multimode file: [network] ops01 ops02 ops03 So…on my 3 servers: dnf remove libreswan wget https://download.libreswan.org/binaries/rhel/8/x86_64/libreswan-3.32-1.el8.x... <https://download.libreswan.org/binaries/rhel/8/x86_64/libreswan-3.32-1.el8.x86_64.rpm> dnf install ./libreswan-3.32-1.el8.x86_64.rpm Reboot maybe….. do I risk breaking everything ? it's really too stupid this story of librewan version and parameters that change Thanks again Franck VEDEL
Le 27 juil. 2021 à 11:12, Bodo Petermann <b.petermann@syseleven.de> a écrit :
Hello Franck,
I tried the ipsec pluto command the vpnaas plugin will use to start pluto on a CentOS 8 with libreswan 4.4 and the command fails:
ipsec pluto --use-netkey --uniqueids /usr/libexec/ipsec/pluto: unrecognized option '--use-netkey' For usage information: /usr/libexec/ipsec/pluto --help Libreswan 4.4
That means that the vpnaas plugin is not up-to-date I'm afraid. Since libreswan 4.0 the option "--use-netkey" is called "--use-xfrm".
The failing pluto command explains the error you copied: "Pluto is not running", but there should also be error messages about the failing ipsec pluto command. I don't know how it could have worked with Victoria and Stream though. Maybe there was an older libreswan? v3.32 might still work as it accepts the "--use-netkey" option.
Unfortunately the ipsec pluto command issued by the plugin can only be fixed in the plugin itself, not by configuration. The only workaround I see for now is to try installing libreswan 3.32. Or switch to strongswan if that is available for CentOS.
Regards Bodo
Am 26.07.2021 um 20:54 schrieb Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr <mailto:franck.vedel@univ-grenoble-alpes.fr>>:
Hello Bodo, hello Radoslaw, thanks a lot for your help. My situation is: In June: 3 test servers. CentOS Stream (8.4). Victoria + Vpnaas: OK Wallaby + Vpnaas: NOT OK
In July: 3 new (different) servers: Rocky OS (8.4) (I changed /etc/system.release to install Openstack) Wallaby + Vpnaas: NOT OK (1), all is working except VPNaaS Victoria + Vpnaas: NOT OK (2), all is working except VPNaaS (thanks Radoslaw for horizon !!)
Error messages for 1): Neutron-l3-agent logs says: Command: ['ipsec', 'whack', '--status'] Exit code: 33 Stdout: Stderr: whack: Pluto is not running (no "/run/pluto/pluto.ctl »)
2): More complete 2021-07-26 20:24:23.352 34 ERROR neutron.agent.linux.utils [-] Exit code: 33; Cmd: ['sudo', 'neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'netns', 'exec', 'qrouter-a63770d5-edad-425d-8330-7d12c2cbf3e4', '/var/lib/kolla/venv/bin/neutron-vpn-netns-wrapper', '--mount_paths=/etc:/var/lib/neutron/ipsec/a63770d5-edad-425d-8330-7d12c2cbf3e4/etc,/var/run:/var/lib/neutron/ipsec/a63770d5-edad-425d-8330-7d12c2cbf3e4/var/run', '--rootwrap_config=/etc/neutron/rootwrap.conf', '--cmd=ipsec,whack,--status']; Stdin: ; Stdout: 2021-07-26 20:24:23.163 39401 INFO neutron.common.config [-] Logging enabled! 2021-07-26 20:24:23.164 39401 INFO neutron.common.config [-] /var/lib/kolla/venv/bin/neutron-vpn-netns-wrapper version 17.1.3.dev54 Command: ['mount', '--bind', '/var/lib/neutron/ipsec/a63770d5-edad-425d-8330-7d12c2cbf3e4/etc', '/etc'] Exit code: 0 Stdout: Stderr: 2021-07-26 20:24:23.186 39401 INFO neutron_vpnaas.services.vpn.common.netns_wrapper [-] /var/lib/neutron/ipsec/a63770d5-edad-425d-8330-7d12c2cbf3e4/etc has been bind-mounted in /etc Command: ['mount', '--bind', '/var/lib/neutron/ipsec/a63770d5-edad-425d-8330-7d12c2cbf3e4/var/run', '/var/run'] Exit code: 0 Stdout: Stderr: 2021-07-26 20:24:23.195 39401 INFO neutron_vpnaas.services.vpn.common.netns_wrapper [-] /var/lib/neutron/ipsec/a63770d5-edad-425d-8330-7d12c2cbf3e4/var/run has been bind-mounted in /var/run Command: ['ipsec', 'whack', '--status'] Exit code: 33 Stdout: Stderr: whack: Pluto is not running (no "/run/pluto/pluto.ctl")
So… I tried what you say: « docker exec -it /bin/bash » « ps aux |grep pluto » ———> no pluto running
You could also check if the configuration has been created properly: /var/lib/neutron/ipsec/{router-id}/etc with ipsec.conf and ipsec.secrets
Yes, configuration is created (i think…..) [neutron@iut1r-srv-ops01-i01 /var/lib/neutron/ipsec/a63770d5-edad-425d-8330-7d12c2cbf3e4/etc]$ ls -l total 8 -rw-r--r--. 1 neutron neutron 0 Jul 26 09:49 hosts -rw-r--r--. 1 neutron neutron 1948 Jul 26 09:49 ipsec.conf drwxr-xr-x. 11 neutron neutron 135 Jul 26 09:49 ipsec.d -rw-------. 1 root root 107 Jul 26 09:49 ipsec.secrets drwxr-xr-x. 3 neutron neutron 19 Jul 26 09:49 pki -rw-r--r--. 1 neutron neutron 0 Jul 26 09:49 resolv.conf
for exemple, the file /var/lib/neutron/ipsec/a63770d5-edad-425d-8330-7d12c2cbf3e4/etc/ipsec.conf is
# Configuration for 2a1446f5-4618-4927-883a-7a8b702e13c1 config setup nat_traversal=yes virtual_private=%v4:10.0.1.0/24,%v4:10.0.2.0/24 conn %default keylife=60m keyingtries=%forever conn 6b588921-a120-402a-bed2-38c55879a432 # NOTE: a default route is required for %defaultroute to work... leftnexthop=%defaultroute rightnexthop=%defaultroute left=172.16.203.154 leftid=172.16.203.154 auto=start # NOTE:REQUIRED # [subnet] leftsubnet=10.0.1.0/24 # [updown] # What "updown" script to run to adjust routing and/or firewalling when # the status of the connection changes (default "ipsec _updown"). # "--route yes" allows to specify such routing options as mtu and metric. leftupdown="ipsec _updown --route yes" ###################### # ipsec_site_connections ###################### # [peer_address] right=172.16.201.79 # [peer_id] rightid=172.16.201.79 # [peer_cidrs] rightsubnets={ 10.0.2.0/24 } # rightsubnet=networkA/netmaskA, networkB/netmaskB (IKEv2 only) # [mtu] mtu=1500 # [dpd_action] dpdaction=hold # [dpd_interval] dpddelay=30 # [dpd_timeout] dpdtimeout=120 # [auth_mode] authby=secret ###################### # IKEPolicy params ###################### #ike version ikev2=never # [encryption_algorithm]-[auth_algorithm]-[pfs] ike=aes128-sha1;modp1536 # [lifetime_value] ikelifetime=3600s # NOTE: it looks lifetime_units=kilobytes can't be enforced (could be seconds, hours, days...) ########################## # IPsecPolicys params ########################## # [transform_protocol] phase2=esp # [encryption_algorithm]-[auth_algorithm]-[pfs] phase2alg=aes128-sha1;modp1536 # [encapsulation_mode] type=tunnel # [lifetime_value] lifetime=3600s # lifebytes=100000 if lifetime_units=kilobytes (IKEv2 only) ... I don’t know if you could see something wrong… but it is really very nice to help me with this problem.
Franck
There are no relevant differences in the VPNaaS plugin between Victoria and Wallaby. Maybe there actually is a difference between Rocky and Stream: the pid directory expected by pluto. At least your error message (no "/run/pluto/pluto.ctl") suggests that. The libreswan driver in the VPNaaS plugin works under the assumption that the run-files reside in /var/run. ipsec commands are run via a wrapper to call the actual command inside a namespace, with /etc/ and /var/run/ bind-mounted.
The real paths are /var/lib/neutron/ipsec/{router-id}/... and in there .../etc and ..,/var/run. In a working setup you should find /var/lib/neutron/ipsec/{router-id}/var/run/pluto/pluto.ctl
So it may be a problem if pluto wants to use /run (not bind-mounted), but the plugin only provides for /var/run (bind-mounted).
Bodo Petermann SysEleven GmbH
Am 26.07.2021 um 15:12 schrieb Radosław Piliszek <radoslaw.piliszek@gmail.com <mailto:radoslaw.piliszek@gmail.com>>:
On Mon, Jul 26, 2021 at 10:39 AM Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr <mailto:franck.vedel@univ-grenoble-alpes.fr>> wrote:
Hello. unfortunately, despite the good functioning of Victoria, the VPNAAS service is not working. Same error as for wallaby:
Command: ['ipsec', 'whack', '--status'] Exit code: 33 Stdout: Stderr: whack: Pluto is not running (no "/run/pluto/pluto.ctl") ; Stderr:
I think it's my fault. I didn't want to install CentOS Stream (not knowing what happened with this distribution), I put Rocky. This is a big mistake. I will start all over again, put CentOS Stream (VPNaas worked with Victoria and CentOS Stream in my tests). Thanks again. I'm still disgusted with all this wasted time.
Hello Franck,
Before you go wrecking your infra - I am pretty sure that Rocky vs Stream does not make a difference here. I thought Victoria worked because you said so but it seems it has always broken in Kolla Ansible and we have a bug to fix: https://bugs.launchpad.net/kolla-ansible/+bug/1869491 <https://bugs.launchpad.net/kolla-ansible/+bug/1869491> VPNaaS is not the most popular enabled option to be honest.
Do you remember how you got it working back then? That could help here.
-yoctozepto
Franck
Le 25 juil. 2021 à 21:25, Radosław Piliszek <radoslaw.piliszek@gmail.com <mailto:radoslaw.piliszek@gmail.com>> a écrit :
On Sun, Jul 25, 2021 at 9:18 PM Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr <mailto:franck.vedel@univ-grenoble-alpes.fr>> wrote:
Oh !! Thanks a lot, really.
Indeed, I installed kolla-ansible 12.0, install wallaby (it works perfectly… expect Vpnaas), then I changed "wallaby" to « victoria » in globals.yml.
And in Wallaby's notes, there is the sentence: The Karbor project is no longer maintained and retired since the Wallaby cycle. Its support and roles are also removed since Wallaby cycle. So, it's not normal that it doesn't work. I understand…. There is a lot of things, it’s not easy to do the right thing the first time.
On the other hand ... and I hope not to abuse, I am not sure I understand "clone https://opendev.org/openstack/kolla-ansible <https://opendev.org/openstack/kolla-ansible>". Do you have to uninstall kolla-ansible 12 before putting 11? How do you do "pip install that directory then"? Really sorry for these stupid questions, but I'm afraid to mess things up.
Sure thing. I meant to use Git. Try these commands:
git clone --branch stable/victoria \ https://opendev.org/openstack/kolla-ansible <https://opendev.org/openstack/kolla-ansible> pip install ./kolla-ansible
-yoctozepto
Franck
Le 25 juil. 2021 à 18:00, Radosław Piliszek <radoslaw.piliszek@gmail.com <mailto:radoslaw.piliszek@gmail.com>> a écrit :
On Sun, Jul 25, 2021 at 2:52 PM Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr <mailto:franck.vedel@univ-grenoble-alpes.fr>> wrote:
Hello
Hello Franck,
Having had no help with my Vpnaas (centos wallaby) problem, I came back to Victoria because I know from having tested that Vpnaas works as it should under Victoria. A few weeks ago, I had the opportunity to use 3 test servers, I had set up Victoria (with Centos and kolla-ansible). No problem, everything was working as I wanted it to. I have since set up 3 new servers to set up an Openstack for my students. if i install Wallaby, no Vpnaas, and I need VPNaaS…. So Victoria.
if I install Victoria, and this is the 1st time that this happens to me, horizon does not work. The horizon docker does not start. The "docker logs horizon" command ends with the following 3 lines: ++ config_karbor_dashboard ++ for file in $ {SITE_PACKAGES} / karbor_dashboard / enabled / _ * [^ __]. py / usr / local / bin / kolla_extend_start: line 121: ENABLE_KARBOR: unbound variable
This error suggests you are using Kolla Ansible Wallaby or later to deploy Victoria. You probably just set "openstack_release" to "Victoria" without downgrading Kolla Ansible to a supported version. There is a reason why "openstack_release" is commented with "Do not override this unless you know what you are doing.". ;-) It is only really meant to be used for very specific tasks, not really meant for regular users. Please have a look at https://docs.openstack.org/releasenotes/kolla-ansible/victoria.html <https://docs.openstack.org/releasenotes/kolla-ansible/victoria.html> The latest release for Victoria is 11.0.0 but there are lots of unreleased fixes so I advise you to just clone https://opendev.org/openstack/kolla-ansible <https://opendev.org/openstack/kolla-ansible> checkout stable/victoria and pip install that directory then. It will fix your current issue.
-yoctozepto
Hello, I am using kolla-ansible to set up my openstack. I'm desperately trying to get Vpnaas to work with Victoria or Wallaby, using CentOS. But a version of the LibreSwan software prevents proper operation. Is it possible to know the version of a software used in a docker image ? I should not use version 4.X but rather version 3.3. I did a test with ussuri, it was version 4.3 so Vpnaas does not work with ussuri and Centos. Thanks in advance Franck
Hello Franck, You can use the rpm tool from inside a container to query package information. For example, running the following command confirms the victoria image includes libreswan-4.3-3: docker run --rm kolla/centos-binary-neutron-l3-agent:victoria rpm -qi libreswan Wallaby uses libreswan-4.4-1, while Ussuri uses libreswan-4.3-3 like Victoria. On Thu, 29 Jul 2021 at 08:29, Franck VEDEL < franck.vedel@univ-grenoble-alpes.fr> wrote:
Hello, I am using kolla-ansible to set up my openstack. I'm desperately trying to get Vpnaas to work with Victoria or Wallaby, using CentOS. But a version of the LibreSwan software prevents proper operation. Is it possible to know the version of a software used in a docker image ? I should not use version 4.X but rather version 3.3. I did a test with ussuri, it was version 4.3 so Vpnaas does not work with ussuri and Centos. Thanks in advance
Franck
Slightly off-topic but I believe we have established it's a bug in VPNaaS in that it does not work with current package versions on a supported platform. I don't know whether it works on Ubuntu. I believe it should work somewhere because Neutron seems to be testing it nonetheless, presumably only ever on Ubuntu. ;-) -yoctozepto On Thu, Jul 29, 2021 at 10:22 AM Franck.vedel@univ-grenoble-alpes.fr <Franck.vedel@univ-grenoble-alpes.fr> wrote:
Hello Pierre Thank you for your help I didn't know this command I hope I will find a solution to have vpnaas with centos but... I'm not optimist now... Maybe the solution is Ubuntu and stringswan. Has someone already tried this? Vpnaas Ubuntu kolla ansible and Victoria or wallaby? I don't want to reinstall with centos stream
Franck
-------- Message original -------- De : Pierre Riteau <pierre@stackhpc.com> Date : jeu. 29 juil. 2021 à 09:53 À : Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr> Cc : openstack-discuss <openstack-discuss@lists.openstack.org> Objet : Re: [kolla-ansible] Is it possible to know software version in docker image ?
Hello Franck,
You can use the rpm tool from inside a container to query package information.
For example, running the following command confirms the victoria image includes libreswan-4.3-3:
docker run --rm kolla/centos-binary-neutron-l3-agent:victoria rpm -qi libreswan
Wallaby uses libreswan-4.4-1, while Ussuri uses libreswan-4.3-3 like Victoria.
On Thu, 29 Jul 2021 at 08:29, Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr> wrote:
Hello, I am using kolla-ansible to set up my openstack. I'm desperately trying to get Vpnaas to work with Victoria or Wallaby, using CentOS. But a version of the LibreSwan software prevents proper operation. Is it possible to know the version of a software used in a docker image ? I should not use version 4.X but rather version 3.3. I did a test with ussuri, it was version 4.3 so Vpnaas does not work with ussuri and Centos. Thanks in advance
Franck
Not knowing the procedures in the event of a bug, what should I do? Report the bug? How? 'Or' What ? The bug is known and if so, how long does it take for a bug fix? how can we be aware of the correction? Looking at the patch page for future releases? (here: https://releases.openstack.org/ or elsewhere?). Ideally, I need a vpnaas service for October. Thanks again anyway. You are helping me tremendously with my problem. Franck
Le 29 juil. 2021 à 10:56, Radosław Piliszek <radoslaw.piliszek@gmail.com> a écrit :
Slightly off-topic but I believe we have established it's a bug in VPNaaS in that it does not work with current package versions on a supported platform. I don't know whether it works on Ubuntu. I believe it should work somewhere because Neutron seems to be testing it nonetheless, presumably only ever on Ubuntu. ;-)
-yoctozepto
On Thu, Jul 29, 2021 at 10:22 AM Franck.vedel@univ-grenoble-alpes.fr <Franck.vedel@univ-grenoble-alpes.fr> wrote:
Hello Pierre Thank you for your help I didn't know this command I hope I will find a solution to have vpnaas with centos but... I'm not optimist now... Maybe the solution is Ubuntu and stringswan. Has someone already tried this? Vpnaas Ubuntu kolla ansible and Victoria or wallaby? I don't want to reinstall with centos stream
Franck
-------- Message original -------- De : Pierre Riteau <pierre@stackhpc.com> Date : jeu. 29 juil. 2021 à 09:53 À : Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr> Cc : openstack-discuss <openstack-discuss@lists.openstack.org> Objet : Re: [kolla-ansible] Is it possible to know software version in docker image ?
Hello Franck,
You can use the rpm tool from inside a container to query package information.
For example, running the following command confirms the victoria image includes libreswan-4.3-3:
docker run --rm kolla/centos-binary-neutron-l3-agent:victoria rpm -qi libreswan
Wallaby uses libreswan-4.4-1, while Ussuri uses libreswan-4.3-3 like Victoria.
On Thu, 29 Jul 2021 at 08:29, Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr> wrote:
Hello, I am using kolla-ansible to set up my openstack. I'm desperately trying to get Vpnaas to work with Victoria or Wallaby, using CentOS. But a version of the LibreSwan software prevents proper operation. Is it possible to know the version of a software used in a docker image ? I should not use version 4.X but rather version 3.3. I did a test with ussuri, it was version 4.3 so Vpnaas does not work with ussuri and Centos. Thanks in advance
Franck
Hello Franck, See https://docs.openstack.org/neutron/latest/contributor/policies/bugs.html#neu... : Neutron (client, core, VPNaaS) maintains all of its bugs in the following Launchpad projects: * Launchpad Neutron [1] The only similar bug I can find is one that was resolved years ago [2]. You should open a new bug report and add details of the failure. Do you have any error messages you can share with the neutron project? [1] https://bugs.launchpad.net/neutron [2] https://bugs.launchpad.net/neutron/+bug/1776840 On Thu, 29 Jul 2021 at 22:13, Franck VEDEL < franck.vedel@univ-grenoble-alpes.fr> wrote:
Not knowing the procedures in the event of a bug, what should I do? Report the bug? How? 'Or' What ? The bug is known and if so, how long does it take for a bug fix? how can we be aware of the correction? Looking at the patch page for future releases? (here: https://releases.openstack.org/ or elsewhere?). Ideally, I need a vpnaas service for October.
Thanks again anyway. You are helping me tremendously with my problem.
Franck
Le 29 juil. 2021 à 10:56, Radosław Piliszek <radoslaw.piliszek@gmail.com> a écrit :
Slightly off-topic but I believe we have established it's a bug in VPNaaS in that it does not work with current package versions on a supported platform. I don't know whether it works on Ubuntu. I believe it should work somewhere because Neutron seems to be testing it nonetheless, presumably only ever on Ubuntu. ;-)
-yoctozepto
On Thu, Jul 29, 2021 at 10:22 AM Franck.vedel@univ-grenoble-alpes.fr <Franck.vedel@univ-grenoble-alpes.fr> wrote:
Hello Pierre Thank you for your help I didn't know this command I hope I will find a solution to have vpnaas with centos but... I'm not optimist now... Maybe the solution is Ubuntu and stringswan. Has someone already tried this? Vpnaas Ubuntu kolla ansible and Victoria or wallaby? I don't want to reinstall with centos stream
Franck
-------- Message original -------- De : Pierre Riteau <pierre@stackhpc.com> Date : jeu. 29 juil. 2021 à 09:53 À : Franck VEDEL <franck.vedel@univ-grenoble-alpes.fr> Cc : openstack-discuss <openstack-discuss@lists.openstack.org> Objet : Re: [kolla-ansible] Is it possible to know software version in docker image ?
Hello Franck,
You can use the rpm tool from inside a container to query package information.
For example, running the following command confirms the victoria image includes libreswan-4.3-3:
docker run --rm kolla/centos-binary-neutron-l3-agent:victoria rpm -qi libreswan
Wallaby uses libreswan-4.4-1, while Ussuri uses libreswan-4.3-3 like Victoria.
On Thu, 29 Jul 2021 at 08:29, Franck VEDEL < franck.vedel@univ-grenoble-alpes.fr> wrote:
Hello, I am using kolla-ansible to set up my openstack. I'm desperately trying to get Vpnaas to work with Victoria or Wallaby, using CentOS. But a version of the LibreSwan software prevents proper operation. Is it possible to know the version of a software used in a docker image ? I should not use version 4.X but rather version 3.3. I did a test with ussuri, it was version 4.3 so Vpnaas does not work with ussuri and Centos. Thanks in advance
Franck
participants (5)
-
Bodo Petermann
-
Franck VEDEL
-
Pierre Riteau
-
Radosław Piliszek
-
Franck.vedel＠univ-grenoble-alpes.fr