Does not add/remove locales on Centos

[bayaro]

Class is changing default locale config but does not check if locale is present/generated in the system.

[saz]

Can you elaborate a little bit more on that?

[bayaro]

I have 3 installed locales in the system: C, POSIX, and en_US.UTF-8.
I need yet one fr_CH.UTF-8 as default.
I have added the config:

class { 'locales':
    default_locale  => 'fr_CH.UTF-8',
    locales         => ['en_US.UTF-8 UTF-8', 'fr_CH.UTF-8 UTF-8'],
  }

and fr_CH.UTF-8 was marked as default, but unfortunately it have not been, and was not installed.
So instead of having a required locale in the system I'm always receiving the warning about absent locale.

[saz]

This is because of no locale_gen_cmd on RedHat based distributions.

[ahoiroman]

On CentOS you could use localedef -v -c -i de_DE -f UTF-8 de_DE.UTF-8.

[kjetilho]

glibc-common (on EL7) runs /usr/sbin/build-locale-archive --install-langs %{_install_langs} in its post script. The RPM macro expands to 'all' by default, and this generates all known locales. This works the same on EL8, but the post script is part of glibc-all-langpacks.

On one of my servers installed more minimally (not by me), the file /etc/rpm/macros.langs contains:

  %_install_langs C:en_US:en_US.UTF-8

(Note colon separated list.)

After an update glibc, the old locales will be removed, and only those locales will be regenerated. A different filename can be used, but I think it is good enough/better to handle this situation. The current value can be checked with the command rpm --eval "%{_install_langs}".

[kjetilho]

Useful info here: http://blog.nashcom.de/nashcomblog.nsf/dx/locale-issue-on-linux-centos-rhel.htm
(Explains the glibc-all-langpacks)

[root@test-centos8 ~]# rpm -q --scripts glibc-minimal-langpack
[root@test-centos8 ~]# rpm --eval "%{_install_langs}"
all
[root@test-centos8 ~]# locale -a
C
C.utf8
POSIX

So .. in EL8, this stuff with the RPM macro is only needed for the package containing all locales. If you install langpacks-en, which pulls in glibc-langpack-en, you get all the English locales, and no post-install scripts to mess with them (_install_langs is still all).

/usr/sbin/build-locale-archive is in glibc-common, though, so it is possible to restrict the locales available.

For EL7, messing with the rpm macro is probably required.

[kjetilho]

This is my quick-fix. I use an exec so I can avoid making the rpm-macro file if there isn't one already, meaning the "all" behaviour is preserved rather than restricted to the list in $locales. Perhaps it would be better to introduce the restrictiveness, but for me that would be a potentially breaking behaviour change on many servers.

Don't really know how to do this cleanly in the module itself.

    if $::osfamily == 'RedHat' and versioncmp($::operatingsystemrelease, '8.0') < 0 {
      # A bit of an ugly hack needed on EL7 where there is no separate
      # glibc-langpack-en.  By default, this RPM macro expands to
      # 'all', which means all locales are generated.  On a minimal
      # install, it is set to only include C and en_US, and we want
      # en_IE.utf8 to get 24 hour time from date etc.  On EL8 we use
      # C.utf8, which is part of the minimal install, but this is
      # unsupported on EL7.
      #
      # See also https://github.com/saz/puppet-locales/issues/48

      Exec { path => '/usr/bin:/bin' }
      exec { 'Update rpm macro _install_langs':
        environment => [
          inline_template('VALUE=%_install_langs <%= @locales.map { |l| l.split(/[. ]/)[0] }.uniq.join(":") %>'),
          'FILE=/etc/rpm/macros.langs',
        ],
        command     => "sh -c 'echo \$VALUE > \$FILE'",
        onlyif      => "sh -c '[ -f \$FILE ] && ! grep -q -x \"\$VALUE\" \$FILE'"
      }
      ~> exec { 'reinstall glibc-common':
        command     => 'yum -y reinstall glibc-common',
        refreshonly => true,
      }
    }

[saz]

As there's no activity on this issue for a longer time, I'll close it. If you think it's still relevant, please let me know.

[kjetilho]

EL7 has not changed behaviour in the interim, and EL7 is still listed as supported by the module, so I am a bit confused why you closed it. You don't really want "any progress?" comments to keep the issue active, do you?

[saz]

It's fine for me to keep the issue open, but I'm not working with EL7 and not able to come up with a proper fix.

I'm happy for any PR which can be merged, but at the same time, I'm not expecting much progress here.

Nobody came up with a PR since 2020, that's why I thought it's just stale.

And, honestly, I'm not tracking the EOL date of EL7.

So, yes, sometimes a "any progress?" can be helpful.