August 2024 - openstack-discuss - lists.openstack.org

[charms] Proposing Jadon Naas and Myles Penner for OpenStack Charms core
by James Page 14 Aug '24

14 Aug '24

Hi everyone I'd like to propose Jadon Naas and Myles Penner for the OpenStack Charms core development team. Jadon has been contributing for over 12 months, providing reviews and direct contributions in a number of areas including figuring out a niggly configuration issue in the OIDC support in Keystone. Myles has been contributing for about 6 months - I'd highlight his work on owning the implementation of audit middleware support in the charms in support of his proposal to the core team. Thank you both for your contributions to the project! Regards James

2 2

networking-onos plugin
by Ganesan, Sathya 14 Aug '24

14 Aug '24

Good Day, Is there an alternative integration available for ONOS and Openstack since networking-onos is archived? Sathya Ganesan Geico Tech | Data Center Core Network Engineering - SDN | sganesan(a)geico.com<mailto:sganesan@geico.com> | 240.478.2121 | M-F 9a-5:30p EST Sensitivity: Company-Internal ==================== This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message.

2 2

[Nova][Keystone] Instance boot fail if user has many roles
by Masahito Muroi 14 Aug '24

14 Aug '24

Hi Nova and Keystone folks, I'd like to get your feedback for the bug[1] and the commit[2]. We use Keystone as company internal role management system and hit the issue frequently. The commit is to change instance_system_metadata table schema, but it could be too big change only for the long role list. Another idea I can imagine is to introduce "store_boot_roles" boolean configuration to store the boot_roles or not. IIUC, the boot_roles is used only by a specific vendor data in the metadata api. If there is another good value to store from Keystone side, I'm happy to use the value instead of role name, too. 1. https://bugs.launchpad.net/nova/+bug/2075100 2. https://review.opendev.org/c/openstack/nova/+/925163 thank you, Masahito

2 3

[kolla] IRC meeting cancelled today
by Bartosz Bezak 14 Aug '24

14 Aug '24

Hello, Unfortunately, due to the unavailability of core team members, we need to cancel today’s Kolla IRC meeting. Apologies for the late notice. Best regards, Bartosz Bezak

1 0

[Glance] Cancelling Weekly Meeting (Aug 15)
by Pranali Deore 14 Aug '24

14 Aug '24

Hello, Cancelling tomorrow's weekly's meeting as 15th August is National Holiday in India and most of the team members will not be around. See you next week!! Thanks, Pranali Deore

1 0

[rabbitmq] Maximum Number of Sessions (8192) Reached
by Eugen Block 14 Aug '24

14 Aug '24

Hi *, I can't seem to find much about rabbitmq and logind, so I wanted to ask the list if anyone has encountered the same and if so, how they dealt with it. We're supporting a Victoria cluster (installed with our own deployment method) mostly controlled by pacemaker. And on the rabbit master node I see this warning constantly: ---snip--- 2024-07-29T14:09:23.552576+02:00 control01 su: pam_unix(su:session): session opened for user rabbitmq by (uid=0) 2024-07-29T14:09:24.450657+02:00 control01 su: pam_unix(su:session): session closed for user rabbitmq 2024-07-29T14:09:24.500356+02:00 control01 su: (to rabbitmq) root on none 2024-07-29T14:09:24.502370+02:00 control01 su: pam_systemd(su:session): Failed to create session: Maximum number of sessions (8192) reached, refusing further sessions. 2024-07-29T14:09:24.502681+02:00 control01 su: pam_unix(su:session): session opened for user rabbitmq by (uid=0) 2024-07-29T14:09:25.565203+02:00 control01 su: pam_unix(su:session): session closed for user rabbitmq 2024-07-29T14:09:25.609613+02:00 control01 su: (to rabbitmq) root on none ---snip--- Looking into loginctl list-sessions, almost all of them belong to rabbitmq and they have a very old timestamp (2023). I'm aware of older systemd versions which can't handle closing sessions correctly [0], but we can't upgrade at this time. Would enabling "linger" fix this (loginctl enable-linger rabbitmq) after a reboot? During the next maintenance window I would reboot control01 and watch how the other control nodes behave wrt rabbit login-sessions. But I'm wondering if somebody already has dealt with this? Thanks for any pointers! Eugen [0] https://www.suse.com/support/kb/doc/?id=000020549

1 2

[manila] Cancelling Aug 15 weekly meeting
by Carlos Silva 14 Aug '24

14 Aug '24

Hello Zorillas and interested stackers, I would like to cancel this week's weekly meeting. Several people from the audience have holidays in their countries/cities or are on PTO. We'll return to our regular weekly meetings on August 22nd. Thank you, carloss

1 0

Report a potential risk of secret leakage in project(cinder)
by jiawei_zhou＠seu.edu.cn 13 Aug '24

13 Aug '24

Dear developers of the project(cinder), We are software security researchers, currently conducting research on secret detection and leakage risk within the open-source ecosystem. In our analysis, we identified potential secret leakage risks in your project, cinder. We provide the detail of our findings in the attachment, which allows you to locate the potential leaked secrets. Below is an interpretation of the attached data: { 'file': '', #The file containing the secret #The project name, version or commit_hash may be reflected in the file path 'line_start': 1, #location: Start line of the secret 'line_end': 28, #location: End line of the secret 'col_start': 1, #location: Start column of the secret 'col_end': 1, #location: End column of the secret 'index_start': 0, #location: Start index of the secret 'index_end': 1675, #location: End index of the secret } Declaration: we hereby declare that we have *NOT* conducted any verification test or exploit on the identified secrets. we plan to publish related research papers in the future, and the relevant content MIGHT BE ACCESS TO THE PUBLIC due to the 90-day disclosure policy. Some advise: 1. If the leaked secret is sensitive and still valid, invalid and rotate the secret immediately. 2. Some secrets seem to be used only in testing environment. Although probably harmless, it is considered bad practices to include secrets for test environment in release builds. Best regards,

3 2

Report a potential risk of secret leakage in project(barbican)
by jiawei_zhou＠seu.edu.cn 13 Aug '24

13 Aug '24

Dear developers of the project(barbican), We are software security researchers, currently conducting research on secret detection and leakage risk within the open-source ecosystem. In our analysis, we identified potential secret leakage risks in your project, barbican. We provide the detail of our findings in the attachment, which allows you to locate the potential leaked secrets. Below is an interpretation of the attached data: { 'file': '', #The file containing the secret #The project name, version or commit_hash may be reflected in the file path 'line_start': 1, #location: Start line of the secret 'line_end': 28, #location: End line of the secret 'col_start': 1, #location: Start column of the secret 'col_end': 1, #location: End column of the secret 'index_start': 0, #location: Start index of the secret 'index_end': 1675, #location: End index of the secret } Declaration: we hereby declare that we have *NOT* conducted any verification test or exploit on the identified secrets. we plan to publish related research papers in the future, and the relevant content MIGHT BE ACCESS TO THE PUBLIC due to the 90-day disclosure policy. Some advise: 1. If the leaked secret is sensitive and still valid, invalid and rotate the secret immediately. 2. Some secrets seem to be used only in testing environment. Although probably harmless, it is considered bad practices to include secrets for test environment in release builds. Best regards,

3 3

Report a potential risk of secret leakage in project(manila_ui)
by jiawei_zhou＠seu.edu.cn 13 Aug '24

13 Aug '24

Dear developers of the project(manila_ui), We are software security researchers, currently conducting research on secret detection and leakage risk within the open-source ecosystem. In our analysis, we identified potential secret leakage risks in your project, manila_ui. We provide the detail of our findings in the attachment, which allows you to locate the potential leaked secrets. Below is an interpretation of the attached data: { 'file': '', #The file containing the secret #The project name, version or commit_hash may be reflected in the file path 'line_start': 1, #location: Start line of the secret 'line_end': 28, #location: End line of the secret 'col_start': 1, #location: Start column of the secret 'col_end': 1, #location: End column of the secret 'index_start': 0, #location: Start index of the secret 'index_end': 1675, #location: End index of the secret } Declaration: we hereby declare that we have *NOT* conducted any verification test or exploit on the identified secrets. we plan to publish related research papers in the future, and the relevant content MIGHT BE ACCESS TO THE PUBLIC due to the 90-day disclosure policy. Some advise: 1. If the leaked secret is sensitive and still valid, invalid and rotate the secret immediately. 2. Some secrets seem to be used only in testing environment. Although probably harmless, it is considered bad practices to include secrets for test environment in release builds. Best regards,

1 0