[Yahoo-eng-team] [Bug 1788045] [NEW] Cannot delete security group rules with unicode chars in their description
Public bug reported: Some editing programs, like gdoc, will mutate double quotes to their unicode equivalent if you haven't disabled that feature. If someone accidentally creates a security group rule with a magic quote (due to an errant copy and paste) they could create a security group with a magic double quote in the description. Subsequent attempts to delete that rule will fail with "Failed to delete rule with name or ID 'fc52f547-300e-43cd-ae8e-833d856b304a': 'ascii' codec can't encode character u'\u201d' in position 136: ordinal not in range(128)" To fix this I had to go into the DB and update the description line to remove the errant magic quote, at which point the delete succeeded. I'm including the following in case anyone else hits this and wants a quick example of how to fix it: mysql> use neutron; mysql> select * from securitygrouprules where id='fc52f547-300e-43cd-ae8e-833d856b304a' \G *** 1. row *** project_id: 335384b960d53910a94b201fbb78a13a id: fc52f547-300e-43cd-ae8e-833d856b304a security_group_id: e595a97d-1729-4686-b5e7-123b4af30dba remote_group_id: e595a97d-1729-4686-b5e7-123b4af30dba direction: ingress ethertype: IPv4 protocol: icmp port_range_min: 11 port_range_max: NULL remote_ip_prefix: 0.0.0.0/0 standard_attr_id: 977 1 row in set (0.00 sec) mysql> select * from standardattributes where id=977; +-++-+-+---+-+ | id | resource_type | created_at | updated_at | description | revision_number | +-++-+-+---+-+ | 977 | securitygrouprules | 2018-08-08 22:37:56 | 2018-08-08 22:37:56 | ICMP Ping”| 0 | +-++-+-+---+-+ 1 row in set (0.00 sec) mysql> update standardattributes set description = "ICMP PING" where id=977; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 (openstack) security group rule delete fc52f547-300e-43cd-ae8e-833d856b304a (openstack) ** Affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1788045 Title: Cannot delete security group rules with unicode chars in their description Status in neutron: New Bug description: Some editing programs, like gdoc, will mutate double quotes to their unicode equivalent if you haven't disabled that feature. If someone accidentally creates a security group rule with a magic quote (due to an errant copy and paste) they could create a security group with a magic double quote in the description. Subsequent attempts to delete that rule will fail with "Failed to delete rule with name or ID 'fc52f547-300e-43cd-ae8e-833d856b304a': 'ascii' codec can't encode character u'\u201d' in position 136: ordinal not in range(128)" To fix this I had to go into the DB and update the description line to remove the errant magic quote, at which point the delete succeeded. I'm including the following in case anyone else hits this and wants a quick example of how to fix it: mysql> use neutron; mysql> select * from securitygrouprules where id='fc52f547-300e-43cd-ae8e-833d856b304a' \G *** 1. row *** project_id: 335384b960d53910a94b201fbb78a13a id: fc52f547-300e-43cd-ae8e-833d856b304a security_group_id: e595a97d-1729-4686-b5e7-123b4af30dba remote_group_id: e595a97d-1729-4686-b5e7-123b4af30dba direction: ingress ethertype: IPv4 protocol: icmp port_range_min: 11 port_range_max: NULL remote_ip_prefix: 0.0.0.0/0 standard_attr_id: 977 1 row in set (0.00 sec) mysql> select * from standardattributes where id=977; +-++-+-+---+-+ | id | resource_type | created_at | updated_at | description | revision_number | +-++-+-+---+-+ | 977 | securitygrouprules | 2018-08-08 22:37:56 | 2018-08-08 22:37:56 | ICMP Ping”| 0 | +-++-+-+---+-+ 1 row in set (0.00 sec) mysql> update standardattributes set description = "ICMP PING" where id=977; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 (openstack) security group rule delete fc52f547-300e-43cd-ae8e-833d856b304a (openstack) To manage notifications about this bug go to:
[Yahoo-eng-team] [Bug 1598783] Re: Config drives created on RHEL/CentOS 7.1 can't be found
** Changed in: cloud-init Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1598783 Title: Config drives created on RHEL/CentOS 7.1 can't be found Status in CirrOS: New Status in cloud-init: Fix Released Status in cloudbase-init: New Bug description: Depending on the exact version of dosfstools used when preparing a config drive FS, it may not be detected by Cirron on VM boot. This is due to the fact, that Cirros currently performs a case-sensitive comparison of FS labels: http://bazaar.launchpad.net/~cirros- dev/cirros/trunk/view/head:/src/lib/cirros/shlib#L134 and mkfs.vfat from CentOS will create an uppercase label "CONFIG-2". Apparently, dosfstools won't let you use lowercase labels on CentOS, while it works fine on Ubuntu: http://paste.openstack.org/show/507193/ All the descriptions of the config drive format mention "config-2", not "CONFIG-2": http://cloudinit.readthedocs.io/en/latest/topics/datasources.html https://coreos.com/os/docs/latest/config-drive.html http://docs.openstack.org/user-guide/cli_config_drive.html Nothing is said about whether case-sensitive or -insensitive string comparison should be used for comparing of FS labels. Looks like FAT standard does not specify how labels should be treated, but Windows (at least XP) stores those in upper-case: "For FAT volumes, volume labels are stored as uppercase regardless of whether they contain lowercase letters. NTFS volume labels retain and display the case used when the label was created." https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs /en-us/label.mspx?mfr=true E.g. in Debian this was considered to be a bug and was fixed: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714971;msg=2 It even was accepted to upstream: https://github.com/dosfstools/dosfstools/commit/465dd8cf8f643bdd39a732e7d7f819a6abdf3d83 and made it to 3.0.22 release. Related bug in MOS: https://bugs.launchpad.net/mos/+bug/1587960 To manage notifications about this bug go to: https://bugs.launchpad.net/cirros/+bug/1598783/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1598783] Re: Config drives created on RHEL/CentOS 7.1 can't be found
** Also affects: cloud-init Importance: Undecided Status: New ** Also affects: cloudbase-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1598783 Title: Config drives created on RHEL/CentOS 7.1 can't be found Status in CirrOS: New Status in cloud-init: New Status in cloudbase-init: New Bug description: Depending on the exact version of dosfstools used when preparing a config drive FS, it may not be detected by Cirron on VM boot. This is due to the fact, that Cirros currently performs a case-sensitive comparison of FS labels: http://bazaar.launchpad.net/~cirros- dev/cirros/trunk/view/head:/src/lib/cirros/shlib#L134 and mkfs.vfat from CentOS will create an uppercase label "CONFIG-2". Apparently, dosfstools won't let you use lowercase labels on CentOS, while it works fine on Ubuntu: http://paste.openstack.org/show/507193/ All the descriptions of the config drive format mention "config-2", not "CONFIG-2": http://cloudinit.readthedocs.io/en/latest/topics/datasources.html https://coreos.com/os/docs/latest/config-drive.html http://docs.openstack.org/user-guide/cli_config_drive.html Nothing is said about whether case-sensitive or -insensitive string comparison should be used for comparing of FS labels. Looks like FAT standard does not specify how labels should be treated, but Windows (at least XP) stores those in upper-case: "For FAT volumes, volume labels are stored as uppercase regardless of whether they contain lowercase letters. NTFS volume labels retain and display the case used when the label was created." https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs /en-us/label.mspx?mfr=true E.g. in Debian this was considered to be a bug and was fixed: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714971;msg=2 It even was accepted to upstream: https://github.com/dosfstools/dosfstools/commit/465dd8cf8f643bdd39a732e7d7f819a6abdf3d83 and made it to 3.0.22 release. Related bug in MOS: https://bugs.launchpad.net/mos/+bug/1587960 To manage notifications about this bug go to: https://bugs.launchpad.net/cirros/+bug/1598783/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
