integ/debian_pkg_dirs

87 lines
2.4 KiB
Plaintext
Raw Normal View History

base/base-passwd
base/cluster-resource-agents
base/dhcp
base/dnsmasq
base/haproxy
base/libfdt
base/lighttpd
base/linuxptp
Debian: Add lvm2 upstream fix for event_activation Historically, with CentOS, we had issues related to LV activation occurring in a non-deterministic way and causing an assortment of provisioning issues. More deterministic LV activation was achieved by setting use_lvmetad = 0 in /etc/lvm/lvm.conf In the migration to Debian, a much more recent version of the lvm2 package is in use. In the intervening versions of lvm2, lvmetad was removed making use_lvmetad and the associated behavior now obsolete. In some current random testing scenarios, emergency mode is seen when booting the Debian ISO. Reviewing the systemd dump of services initiating when emergency mode occurs, it is observed that LV activation is occurring at a different time and order vs. a successful boot. The Debian lvm2 version provides configuration parameter global/event_activation which when set to 0 will change LV activation behavior when a PV appears. No noticable change was observed when this variable is set. The current upstream version from Debian Bullseye is missing an lvm2 upstream patch the should address this issue. Patch the Debian lvm2 version with this upstream patch to enable testing with this enabled. Test Plan: PASS - Build ISO, install/provision in AIO-SX virtual/hardware labs PASS - Perform numerous reboot cycles an observe no issues PASS - Test on H/W setup that has shown energency mode behavior to confirm that this version and associated config file change resolved emergency mode PV/LV activation issues Change-Id: If22e446126f33c2155bd70988ed9b0444d230730 Partial-Bug: #1979105 Signed-off-by: Robert Church <robert.church@windriver.com>
2022-06-17 21:59:33 -04:00
base/lvm2
base/lsb
base/pf-bb-config
base/systemd
base/watchdog
centos-debian-compat
ceph/ceph
config/facter
config/puppet-5.5.22
config/puppet-modules/openstack/puppet-ceph-2.4.1
config/puppet-modules/openstack/puppet-keystone-17.4.0
config/puppet-modules/openstack/puppet-horizon-17.4.0
config/puppet-modules/openstack/puppet-openstacklib-17.4.0
config/puppet-modules/openstack/puppet-oslo-17.4.0
config/puppet-modules/puppet-boolean-2.0.2
config/puppet-modules/puppet-dnsmasq
config/puppet-modules/puppet-drbd-0.5.2
config/puppet-modules/puppet-etcd-1.12.3
Enable puppet-firewall parsing of --random-fully rules A problem may occur if puppet attempts to inject a firewall rule while the underlying iptables/ip6tables has existing rules which use the --random-fully flag in the NAT table. The issue occurs because puppet-firewall first makes a call to iptables-save/ip6tables-save to parse the existing rules (to determine if the rule already exists). If it finds a rule with --random-fully, it will immediately bail out. The current version(s) of puppet-firewall in StarlingX are old enough that they don't have parsing logic for the --random-fully flag that was initially supported in iptables version 1.6.2+. Now that StarlingX uses iptables 1.8.4, we must account for the possibility that various components (ie. kubernetes) will make use of --random-fully rules. This feature has been implemented upstream in the following commits: https://github.com/puppetlabs/puppetlabs-firewall/commits/ 9a4bc6a81cf0cd4a56ba458fadac830a2c4df529 0ea2b74c0b4a451a37bae8c2ff105b72481ab485 The above commits have been ported back to: CentOS: puppet-firewall-1.8.2 Debian: puppetlabs-firewall-1.12.0 Since StarlingX does not currently build it's own version of puppet-firewall in either CentOS or Debian, this commit also contains the infrastructure to do so. Testing: Note: Since the issue is intermittent on unlock, the functional tests were performed with a custom runtime manifest that installed a dummy iptables/ip6tables rule when an interface was modified. At this time, it was guaranteed that there were rules with the --random-fully flag present. CentOS: Package build: PASS Present in iso: PASS IPv4 functional test (iptables): PASS IPv6 functional test (ip6tables): PASS Debian: Package build: PASS Present in iso: PASS IPv4 functional test (iptables): PASS IPv6 functional test (ip6tables): PASS Closes-Bug: #1971900 Signed-off-by: Steven Webster <steven.webster@windriver.com> Change-Id: I7dbb9e1b99d95df0aa5a7db7aa22c3c314253788
2022-04-29 15:08:25 -04:00
config/puppet-modules/puppetlabs-firewall-1.12.0
config/puppet-modules/puppetlabs-haproxy-2.1.0
Debian: Fix deps on openstacklib, mysql modules The following dependencies were generating the warning "module 'openstacklib' has unresolved dependencies" during bootstrap and unlock on Debian: puppetlabs-openstacklib (v17.4.0) asks for puppetlabs-postgresql version >=6.4.0 <7.0.0 puppetlabs-mysql (v8.1.0) asks for puppetlabs-translate version >= 1.0.0 < 2.0.0 Comparing puppetlabs-postgresql v8.0.0 with v6.10.2: It can be verified that support for Debian 11 was added on v7.4.0, which is already out of the specified range. Other than added functionality and fixes, here are the major changes between v6.10.2(latest version inside of range) and v8.0.0: v7.0.0 drops support for SLES 11 and RHEL 5, and bumps minimum Puppet version to 6.0.0 (We are currently using Puppet 5.5.22, but it should be noted that the minimal version was bumped up because Puppet 5 was removed from the test cases and not because there are signs of malfunction). v8.0.0 drops support for CentOS 6, Debian 6, and Ubuntu 10, which is not a problem since we are not using any of those OSs. In conclusion, any version earlier than v7.4.0 should not be used and there are no known disadvantages to using v8.0.0 instead of v7.4.0. puppetlabs-translate v2.0.0 removes support for Debian 7 and bumps up the minimum Puppet version (both of those are irrelevant here since we are on Debian 11 and the Puppet version is still inside the range). All other changes introduced from v2.0.0 to v2.2.0 are added support and minor fixes. Therefore, it should be safe to use v2.2.0 without a problem. Debian Bullseye tests: PASS: Build & install PASS: Successful Bootstrap PASS: Successful Unlock Story: 2009964 Task: 45496 Signed-off-by: Matheus Machado Guilhermino <Matheus.MachadoGuilhermino@windriver.com> Change-Id: I73fe64b867026ba38b0db7b0a8b34fed388e4d66
2022-05-30 11:19:38 -03:00
config/puppet-modules/puppetlabs-mysql-8.1.0
config/puppet-modules/puppetlabs-postgresql-8.0.0
config/puppet-modules/puppetlabs-stdlib-5.0.0
config/puppet-modules/puppet-ldap
config/puppet-modules/puppet-lvm-1.4.0
config/puppet-modules/puppet-network
config/puppet-modules/puppet-puppi
config/puppet-modules/puppet-rabbitmq-8.5.0
config/puppet-modules/puppet-staging
docker/python-docker
filesystem/drbd/drbd-tools
filesystem/parted
golang-github-dev/golang-github-appc-cni
golang-github-dev/golang-github-checkpoint-restore-go-criu-dev
golang-github-dev/golang-github-cilium-ebpf-dev
golang-github-dev/golang-github-coreos-go-systemd-dev
golang-github-dev/golang-github-opencontainers-specs-dev
golang-github-dev/golang-github-vishvananda-netlink
gpu/gpu-operator
grub/grub2
grub/grubby
kubernetes/armada
kubernetes/armada-helm-toolkit
kubernetes/chartmuseum
kubernetes/cni/bond-cni
kubernetes/cni/plugins
kubernetes/containerd
kubernetes/crictl
kubernetes/docker-distribution
kubernetes/etcd
kubernetes/helm
kubernetes/k8s-cni-cache-cleanup
kubernetes/k8s-pod-recovery
kubernetes/kubernetes-1.21.8
kubernetes/kubernetes-1.23.1
kubernetes/kubernetes-unversioned
kubernetes/plugins/isolcpus-device-plugin
kubernetes/runc
ldap/ldapscripts
ldap/openldap
livepatch/kpatch
networking/ifupdown-extra
Debian: Patch ping for replies with wrong source This commit patches iputils-ping in Debian-based StarlingX so that ping prints out ICMP echo replies with unexpected/"wrong" source IP addresses as was done with CentOS 7's version of ping and as is done with more recent versions of the iputils package. As an example, if the user calls "ping 192.168.1.1" and the ICMP echo responses are sent by 192.168.1.3, then the version of ping in Debian 11 currently assumes that no responses have been received. This issue was discovered while running the eBPF test cases in the kernel's samples/bpf source sub-directory. This issue was introduced upstream with the following commit: 5e052ada96c3 ("ping: discard packets with wrong source address") https://github.com/iputils/iputils/commit/5e052ada96c3 The following commit fixes this issue: 5f6bec5ab57c ("ping: Print reply with wrong source with warning") https://github.com/iputils/iputils/commit/5f6bec5ab57c Due to a number of contextual dependencies, we unfortunately cannot directly cherry-pick the commit that fixes this issue. Hence, we cherry-pick four patches in total. We did not opt for completely uprevisioning the iputils package to be able to inherit bug fixes that Debian may introduce in the future. We checked the list of commits between the two tags 20210202 and 20211215 using the following command: git log --oneline refs/tags/20210202..origin/master -- 'ping/*.[ch]' And we did not find any commits that fix issues in the commits that we are cherry-picking with this commit. Testing: - An ISO image with the standard kernel was successfully incrementally built with this commit. - The resulting ISO image was installed onto a qemu/KVM-based virtual machine and the resulting system was bootstrapped with Ansible and unlocked. - The test cases shipped in the kernel repository's samples/bpf sub-directory were successfully executed in the virtual machine. These test cases make use of ping in IPv4 and IPv6 mode, which ought to be a good sanity test. Partial-Bug: 1977849 Change-Id: I25b42b8de80deec86be0eb504442992863a8d833 Signed-off-by: M. Vefa Bicakci <vefa.bicakci@windriver.com>
2022-05-30 19:49:32 +00:00
networking/iputils
networking/lldpd
networking/net-tools
ostree/initramfs-ostree
ostree/mttyexec
ostree/ostree
ostree/ostree-upgrade-mgr
python/dh-python
python/python-nss
python/python3-setuptools
security/keyrings.alt
security/python-keyring
security/shim-unsigned
security/openscap
storage-drivers/trident-installer
tools/kdump-tools