[Bug 1883074] Re: After system reboot conn fails until swanctl restart

2020-06-11 Thread Volodymyr Litovka
Tobias, thank you!

** Changed in: strongswan (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1883074

Title:
  After system reboot conn fails until swanctl restart

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1883074/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1883074] Re: After system reboot conn fails until swanctl restart

2020-06-11 Thread Volodymyr Litovka
Hi Tobias,

I'm not using ipsec.conf, just swanctl.conf

Do you mean, that having this configuration:

root@newton:~# systemctl |egrep -i "swan|charon"
strongswan-swanctl.service loaded active running   strongSwan IPsec IKEv1/IKEv2 
daemon using swanctl
strongswan.service loaded active running   strongSwan IPsec IKEv1/IKEv2 
daemon using ipsec.conf

it's both safe and enough to disable strongswan.service and leave
enabled just strongswan-swanctl.service?

Thank you.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1883074

Title:
  After system reboot conn fails until swanctl restart

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1883074/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1883074] [NEW] After system reboot conn fails until swanctl restart

2020-06-11 Thread Volodymyr Litovka
Public bug reported:

Dear colleagues,

- Ubuntu 18.04 LTS
- charon-systemd   5.6.2-1ubuntu2.5
- libcharon-extra-plugins  5.6.2-1ubuntu2.5
- libcharon-standard-plugins   5.6.2-1ubuntu2.5
- libstrongswan5.6.2-1ubuntu2.5
- libstrongswan-extra-plugins  5.6.2-1ubuntu2.5
- libstrongswan-standard-plugins   5.6.2-1ubuntu2.5
- strongswan   5.6.2-1ubuntu2.5
- strongswan-charon5.6.2-1ubuntu2.5
- strongswan-libcharon 5.6.2-1ubuntu2.5
- strongswan-starter   5.6.2-1ubuntu2.5
- strongswan-swanctl   5.6.2-1ubuntu2.5
- strongswan-tnc-base  5.6.2-1ubuntu2.5

System configured and accepts incoming IPSec connections. But after
reboot any connection fails with the following reason:

Jun 11 00:55:22 newton strongswan: 02[IKE] <2> no IKE config found for
..., sending NO_PROPOSAL_CHOSEN

until "systemctl restart strongswan-swanctl.service"

After I added "stronswan.service" to swanctl's service definition in
parameters 'After' and 'Wants':

root@newton:~# cat 
/etc/systemd/system/strongswan-swanctl.service.d/override.conf
[Unit]
After=network-online.target strongswan.service
Wants=strongswan.service

problem seems gone.

Not bad to fix this issue in package.

Thank you.

** Affects: strongswan (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1883074

Title:
  After system reboot conn fails until swanctl restart

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1883074/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1824340] Re: DHCPv4 can't set route

2019-04-12 Thread Volodymyr Litovka
Hello, Dan

in fact, I recently submitted patch to Openstack Neutron, which reorder
Opt.121 records before sending them to the host. I think it's more
relevant way - change server's behaviour rather than change all possible
clients. I think it makes sense to mark this bug as invalid.

Answering your questions:

BEFORE I applied the patch, dnsmasq's 'opts' was these:

tag:tag1,option:dns-server,...list of servers...
tag:tag1,option:classless-static-route,2.2.2.0/24,10.0.2.22,10.0.2.0/24,0.0.0.0,169.254.169.254/32,10.0.3.1,0.0.0.0/0,10.0.3.1
tag:tag1,249,2.2.2.0/24,10.0.2.22,10.0.2.0/24,0.0.0.0,169.254.169.254/32,10.0.3.1,0.0.0.0/0,10.0.3.1tag:tag1,option:router,10.0.3.1

AFTER patch, options 121 and 249 changed to:

tag:tag1,option:classless-static-
route,10.0.2.0/24,0.0.0.0,2.2.2.0/24,10.0.2.22,169.254.169.254/32,10.0.3.1,0.0.0.0/0,10.0.3.1

Thank you.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1824340

Title:
  DHCPv4 can't set route

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1824340/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1824340] [NEW] DHCPv4 can't set route

2019-04-11 Thread Volodymyr Litovka
Public bug reported:

Dear colleagues,

I'm facing the problem in systemd-networkd with processing classless
routes (in fact, I'm using netplan, but netplan use networkd).
Environment is below.

The problem:
DHCP server sends the following classless routes in Opt.121 (in the following 
sequence):

3.3.3.0/24 -> 10.0.3.14
10.0.3.0/24 -> 0.0.0.0

and systemd-networkd fails with the message:

Apr 11 11:11:40 mother systemd-networkd[8357]: eth1: DHCPv4 address 10.0.2.15/24
Apr 11 11:11:40 mother systemd-networkd[8357]: eth1: DHCP: No routes received 
from DHCP server: No data available
Apr 11 11:11:40 mother systemd-networkd[8357]: eth1: Could not set DHCPv4 
route: Network is unreachable
Apr 11 11:11:40 mother systemd-networkd[8357]: eth1: Failed

The cause is clear - at the moment when 3.3.3.0/24 appears, there is no
route to it's nexthop (10.0.3.14).

Default behavior of ISC DHCP client is the same but can be fixed in two
ways:

1) second run of dhclient installs 3.3.3.0/24 since 10.0.3.14 is accessible 
since first run
2) OR changing /etc/dhcp/dhclient-exit-hooks.d/rfc3442-classless-routes in 
order to process connected routes (i.e. gateway is 0.0.0.0) first, while other 
routes - next.

Is it possible to modify systemd-networkd behavior in some way? -
1) sort routes and install connected first and other - next?
2) OR use kind of max_retries after which systemd-networkd's dhcp client will 
fail finally
3) OR add ability to use own scripts like mentioned above ISC's hook?

Any recommendation on how to work around this issue are highly
appreciated.

Thank you.

Environment:
OS: Ubuntu 18.04.2
systemd: 237
DNS server: dnsmasq (Openstack)
Netplan: 0.40.1~18.04.4

** Affects: systemd (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1824340

Title:
  DHCPv4 can't set route

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1824340/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1559072] Re: [SRU] exceptions.from_response with webob 1.6.0 results in "AttributeError: 'unicode' object has no attribute 'get'"

2017-06-05 Thread Volodymyr Litovka
Openstack: stable/ocata
Ubuntu 16.04.02 Xenial Xerus

$ openstack server list
+--++---+
| ID   | Name   | Status|
+--++---+
| 54b2465f-6a5d-467e-8815-42c436852ba6 | jex-n1 | ACTIVE|
| a0442c11-dc5b-4d8f-9e77-a83b59782b7c | jex-n2 | SUSPENDED |
+--++---+

$ openstack server rebuild jex-n1   
'unicode' object has no attribute 'get'

== --debug - ===
GET call to compute for http://controller:8774/v2.1/servers?name=jex-n1 used 
request id req-def51157-4adb-4c37-9ccf-77a8124fa939
REQ: curl -g -i -X GET 
http://controller:8774/v2.1/servers/54b2465f-6a5d-467e-8815-42c436852ba6 -H 
"User-Agent: python-novaclient" -H "Accept: application/json" -H "X-Auth-Token: 
{SHA1}7970e0bb2968bd69cc6f49026ba350e55da7b105"
http://controller:8774 "GET /v2.1/servers/54b2465f-6a5d-467e-8815-42c436852ba6 
HTTP/1.1" 200 1782
RESP: [200] Content-Length: 1782 Content-Type: application/json 
Openstack-Api-Version: compute 2.1 X-Openstack-Nova-Api-Version: 2.1 Vary: 
OpenStack-API-Version, X-OpenStack-Nova-API-Version X-Compute-Request-Id: 
req-4e02c928-6dbc-4f79-9cc9-1ca0ad8e69e3 Date: Mon, 05 Jun 2017 10:44:16 GMT
RESP BODY: {"server": {"OS-EXT-STS:task_state": null, "addresses": {"e-net": 
[{"OS-EXT-IPS-MAC:mac_addr": "d0:1c:a0:04:a4:5d", "version": 4, "addr": 
"51.255.0.248", "OS-EXT-IPS:type": "fixed"}], "jex-net": 
[{"OS-EXT-IPS-MAC:mac_addr": "d0:1c:a0:74:f8:57", "version": 4, "addr": 
"1.1.1.10", "OS-EXT-IPS:type": "fixed"}], "dummy-net": 
[{"OS-EXT-IPS-MAC:mac_addr": "d0:1c:a0:8c:ae:f2", "version": 4, "addr": 
"25.0.0.7", "OS-EXT-IPS:type": "fixed"}]}, "links": [{"href": 
"http://controller:8774/v2.1/servers/54b2465f-6a5d-467e-8815-42c436852ba6";, 
"rel": "self"}, {"href": 
"http://controller:8774/servers/54b2465f-6a5d-467e-8815-42c436852ba6";, "rel": 
"bookmark"}], "image": "", "OS-EXT-STS:vm_state": "active", 
"OS-EXT-SRV-ATTR:instance_name": "instance-016f", "OS-SRV-USG:launched_at": 
"2017-06-05T08:53:58.00", "flavor": {"id": 
"d0ff4bc5-df38-4f20-8908-afc516d594e6", "links": [{"href": 
"http://controller:8774/flavors/d0ff4bc5-df38-4f20-8908-afc516d594e6";, "rel": 
"bookmark"}]}, "id": "54b246
 5f-6a5d-467e-8815-42c436852ba6", "security_groups": [{"name": "default"}, 
{"name": "jex-esg"}], "user_id": "0d01892c43b0498198c4716d510c6667", 
"OS-DCF:diskConfig": "MANUAL", "accessIPv4": "", "accessIPv6": "", "progress": 
0, "OS-EXT-STS:power_state": 1, "OS-EXT-AZ:availability_zone": "nova", 
"metadata": {}, "status": "ACTIVE", "updated": "2017-06-05T08:53:59Z", 
"hostId": "4c5f24a68ef88f97beb99c3e34d5ea6cba6d3fabe3dc5a6487ed8415", 
"OS-EXT-SRV-ATTR:host": "ardbeg", "OS-SRV-USG:terminated_at": null, "key_name": 
null, "OS-EXT-SRV-ATTR:hypervisor_hostname": "compute0.cloud.local", "name": 
"jex-n1", "created": "2017-06-05T08:53:42Z", "tenant_id": 
"d8051a3ff3ad4c4bb380f828992b8178", "os-extended-volumes:volumes_attached": 
[{"id": "d76e23e8-c6cb-462e-9ac0-81b2d733fc77"}], "config_drive": ""}}
GET call to compute for 
http://controller:8774/v2.1/servers/54b2465f-6a5d-467e-8815-42c436852ba6 used 
request id req-4e02c928-6dbc-4f79-9cc9-1ca0ad8e69e3
'unicode' object has no attribute 'get'
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/cliff/app.py", line 400, in 
run_subcommand
result = cmd.run(parsed_args)
  File "/usr/lib/python2.7/dist-packages/osc_lib/command/command.py", line 41, 
in run
return super(Command, self).run(parsed_args)
  File "/usr/lib/python2.7/dist-packages/cliff/display.py", line 112, in run
column_names, data = self.take_action(parsed_args)
  File "/usr/lib/python2.7/dist-packages/openstackclient/compute/v2/server.py", 
line 1215, in take_action
image_id = parsed_args.image or server._info.get('image', {}).get('id')
AttributeError: 'unicode' object has no attribute 'get'
clean_up RebuildServer: 'unicode' object has no attribute 'get'
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/osc_lib/shell.py", line 135, in run
ret_val = super(OpenStackShell, self).run(argv)
  File "/usr/lib/python2.7/dist-packages/cliff/app.py", line 279, in run
result = self.run_subcommand(remainder)
  File "/usr/lib/python2.7/dist-packages/osc_lib/shell.py", line 180, in 
run_subcommand
ret_value = super(OpenStackShell, self).run_subcommand(argv)
  File "/usr/lib/python2.7/dist-packages/cliff/app.py", line 400, in 
run_subcommand
result = cmd.run(parsed_args)
  File "/usr/lib/python2.7/dist-packages/osc_lib/command/command.py", line 41, 
in run
return super(Command, self).run(parsed_args)
  File "/usr/lib/python2.7/dist-packages/cliff/display.py", line 112, in run
column_names, data = self.take_action(parsed_args)
  File "/usr/lib/python2.7/dist-packages/openstackclient/compute/v2/server.py", 
line 1215, in take_action
image_id =