https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# harvester
a
This message was deleted.
a
Check github.com/harvester/harvester/blob/…/cos.go#…
Copy code
# cat /oem/90_custom.yaml
name: Harvester Configuration
stages:
    after-install-chroot:
        - commands:
            - mkdir -p /etc/ssh/sshd_config.d
            - "echo 'Subsystem\tsftp\t/usr/libexec/ssh/sftp-server' > /etc/ssh/sshd_config.d/sftp.conf"
          if: '[ ! -f "/run/cos/recovery_mode" ]'
          name: Run after-install-chroot commands
    initramfs:
        - commands:
...
👍 1
b
Thanks. That's the 1.7 version, in 1.6 the sftp server was still in /usr/lib, but that helps!
@abundant-account-48953 Is this from an upgraded Harvester? Or was it installed from scratch?
How is this working if the cluster was upgraded from e.g. 1.6 or earlier (the feature was introduced in 1.3 if Google is correct) and the subsystem contains the wrong path? My Github source search foo in the commit history is sadly not working..
a
This code snippet is from a fresh installed 1.8.0 or 1.9.0 system (don't know it anymore). According to github.com/harvester/harvester/blob/…/upgrade_node.sh#… the path is migrated during upgrade.
The path migration will be done during upgrade 1.6 to 1.7, see github.com/harvester/harvester/pull/9303
b
Thanks, I know that already. I have a bunch of 1.6.1 here which need to be adjusted before they are upgraded to 1.7.2. This is why I wanted to know how this looks like in 1.6.
I reinstalled one 1.6.1 node with the sftp option. This results in 90_custom.yaml:
Copy code
stages:
    after-install-chroot:
        - commands:
            - mkdir -p /etc/ssh/sshd_config.d
            - "echo 'Subsystem\tsftp\t/usr/lib/ssh/sftp-server' > /etc/ssh/sshd_config.d/sftp.conf"
I verified, that this command is executed at every reboot. Good enough as long as we're running <=1.6.1. Now I'm ugprading to 1.7.1. The path to the 
sftp-server
is changing, and the 
upgrade-node.sh
script is "fixing" it at upgrade time, exactly once(!). But 90_custom.yaml is not adjusted (I assume that, I didn't test it yet, but 90_custom.yaml was never adjusted in the past, so why now?). Which means that after each reboot the wrong content is reconciled into the file, breaking the sftp feature in >=1.7.x. I saw that you guys created github.com/harvester/harvester/issues/11153 which makes me assume that it's exactly working (or better not working) as I described above. Correct?
I think about disabling the sftp feature in the cluster config again and maintaining it on my own. Which is imho a really bad thing to do. Do you have any better suggestion? @abundant-account-48953
After the upgrade to v1.7.2 the 
sftp.conf
file still contains the old content (/usr/lib/ssh/sftp-server instead of /usr/libexec/ssh/sftp-server). This was, sort of, expected. Even though the node-upgrade.sh probably changed it at upgrade time, the reconciliation of 90_custom.yaml at each reboot restored the old (now wrong) content. The upgrade procedure should either change 90_custom.yaml or remove it and e.g. replace it with a cloud-init resource. I created a case to track this issue. EDIT: I tried to re-create it one more time and it didn't work. Not sure what I did wrong... either the first time or the last time. Still: The whole topic is confusing and requires attention, imho.
2 Views
Open in Slack
PreviousNext
Powered by