scp'ing a podman image to another host
I have an image on RH 8.x which runs fine (containing a SuSE SLES and PostgreSQL server): $ podman images REPOSITORY TAG IMAGE ID CREATED SIZE localhost/suse latest c87c80c0911a 26 hours ago 6.31 GB registry.suse.com/bci/bci-base 15.4 5bd0e4152d92 2 weeks ago 123 MB I created a connection to another host as: $ podman system connection list Name URI Identity Default srap57 ssh://apitzm@srap57dxr1.dev.xxxxxx.org:22/run/user/200007/podman/podman.sock true To the other host I can SSH fine based on RSA public/private keys and podman is installed there to: $ ssh apitzm@srap57dxr1.dev.xxxxxx.org Last login: Wed Jan 10 14:05:12 2024 from 10.201.64.28 apitzm@srap57dxr1:~> podman version Client: Podman Engine Version: 4.7.2 API Version: 4.7.2 Go Version: go1.21.4 Built: Wed Nov 1 13:00:00 2023 When I now copy over the image with: $ podman image scp c87c80c0911a srap57:: it transfers the ~6 GByte (I can see them in /tmp as a big tar file of tar files) and at the end it says: ... Writing manifest to image destination $ (i.e. the shell prompt is there again) But on srap57dxr1.dev.xxxxxx.org I can't see anything of the image at the end. What I've done wrong? Thanks matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub I am not at war with Russia. Я не воюю с Россией. Ich bin nicht im Krieg mit Russland.
You should also usually get some sort of: Storing signaturesLoaded image(s): after Writing manifest to image destination if this doesn't show up, then the image doesn't actually get stored. I remember there being some compatibility issues over certain types/sizes of images w/ scp. Can you throw a `-v` in there to see if it tells you anything else? Charlie On Wed, Jan 10, 2024 at 9:33 AM Matthias Apitz <guru@unixarea.de> wrote:
I have an image on RH 8.x which runs fine (containing a SuSE SLES and PostgreSQL server):
$ podman images REPOSITORY TAG IMAGE ID CREATED SIZE localhost/suse latest c87c80c0911a 26 hours ago 6.31 GB registry.suse.com/bci/bci-base 15.4 5bd0e4152d92 2 weeks ago 123 MB
I created a connection to another host as:
$ podman system connection list Name URI Identity Default srap57 ssh:// apitzm@srap57dxr1.dev.xxxxxx.org:22/run/user/200007/podman/podman.sock true
To the other host I can SSH fine based on RSA public/private keys and podman is installed there to:
$ ssh apitzm@srap57dxr1.dev.xxxxxx.org Last login: Wed Jan 10 14:05:12 2024 from 10.201.64.28 apitzm@srap57dxr1:~> podman version Client: Podman Engine Version: 4.7.2 API Version: 4.7.2 Go Version: go1.21.4 Built: Wed Nov 1 13:00:00 2023
When I now copy over the image with:
$ podman image scp c87c80c0911a srap57::
it transfers the ~6 GByte (I can see them in /tmp as a big tar file of tar files) and at the end it says:
... Writing manifest to image destination $
(i.e. the shell prompt is there again)
But on srap57dxr1.dev.xxxxxx.org I can't see anything of the image at the end.
What I've done wrong?
Thanks
matthias
-- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
I am not at war with Russia. Я не воюю с Россией. Ich bin nicht im Krieg mit Russland. _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
El día miércoles, enero 10, 2024 a las 10:09:27 -0500, Charlie Doern escribió:
You should also usually get some sort of:
Storing signaturesLoaded image(s):
after
Writing manifest to image destination
There is not. I was expecting this also.
if this doesn't show up, then the image doesn't actually get stored. I remember there being some compatibility issues over certain types/sizes of images w/ scp. Can you throw a `-v` in there to see if it tells you anything else?
There is no -v flag. -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub I am not at war with Russia. Я не воюю с Россией. Ich bin nicht im Krieg mit Russland.
El día miércoles, enero 10, 2024 a las 10:09:27 -0500, Charlie Doern escribió:
You should also usually get some sort of:
Storing signaturesLoaded image(s):
after
Writing manifest to image destination
if this doesn't show up, then the image doesn't actually get stored. I remember there being some compatibility issues over certain types/sizes of images w/ scp. Can you throw a `-v` in there to see if it tells you anything else?
I did tests in two directions: 1) On the source host I run: $ podman run -it docker.io/library/busybox which gave me a local additional image and I transfered this to the target host: $ podman images REPOSITORY TAG IMAGE ID CREATED SIZE localhost/suse latest c87c80c0911a 46 hours ago 6.31 GB registry.suse.com/bci/bci-base 15.4 5bd0e4152d92 2 weeks ago 123 MB docker.io/library/busybox latest 9211bbaa0dbd 3 weeks ago 4.5 MB $ podman image scp 9211bbaa0dbd srap57:: Copying blob 82ae998286b2 done Copying config 9211bbaa0d done Writing manifest to image destination Loaded image: sha256:9211bbaa0dbd68fed073065eb9f0a6ed00a75090a9235eca2554c62d1e75c58f i.e. this was transfered fine and shows up on the target host as: srap57dxr1:~> podman images REPOSITORY TAG IMAGE ID CREATED SIZE <none> <none> b677170ada05 3 minutes ago 1.89 GB registry.suse.com/bci/bci-base 15.4 5bd0e4152d92 2 weeks ago 123 MB <none> <none> 9211bbaa0dbd 3 weeks ago 4.49 MB apitzm@srap57dxr1:~> podman run -t 9211bbaa0dbd / # 2) I copied over the files to build the image to the target host: apitzm@srrp02dxr1:~$ scp -rp suse srap57dxr1:. Dockerfile 100% 5051 1.2MB/s 00:00 initSunRise.sh 100% 953 314.2KB/s 00:00 postgresql.conf 100% 29KB 5.0MB/s 00:00 testdb.dmp.gz 100% 388MB 110.0MB/s 00:03 keyFile 100% 893 63.2KB/s 00:00 and built the image there with: apitzm@srap57dxr1:~> podman build -t suse suse ... which worked also fine: ... STEP 58/59: ENTRYPOINT /usr/local/bin/start.sh --> 86dab7ac3e4d STEP 59/59: STOPSIGNAL SIGQUIT COMMIT suse --> a1ffb1f71791 Successfully tagged localhost/suse:latest a1ffb1f717911b4e11aaa89d94c4959562c625b0e203dd906797e60d019cde57 The big difference between the image 'docker.io/library/busybox' and mine is the size (4,5 MB ./. 6,1 GB). When I scp my big image I see in /tmp that the sftp-server writes there a temp. file as: ls -lh /tmp/tmp.RLHbJp9uzq -rw------- 1 apitzm apitzm 5.8G Jan 11 10:58 /tmp/tmp.RLHbJp9uzq and when this reached the size of 6 GB it gets deleted 3) I removed all container files on the target host: srap57dxr1:/ # rm -rf /data/guru/containers/* srap57dxr1:/ # du -sh /data/guru/containers/ 1.0K /data/guru/containers/ and started a fresh scp: $ podman image scp c87c80c0911a srap57:: ... Copying blob a5a080851ed7 done Copying blob 6fc7ff0cb132 done Copying config c87c80c091 done Writing manifest to image destination When the transfer has ended on the target host one can see 1. the big file in /tmp gets deleted 2. something was written below the area of the containers (which was empty before): srap57dxr1:/# ls -lh /tmp/tmp.5uuhYWqqQT -rw------- 1 apitzm apitzm 4.3G Jan 11 11:35 /tmp/tmp.5uuhYWqqQT srap57dxr1:/# ls -lh /tmp/tmp.5uuhYWqqQT -rw------- 1 apitzm apitzm 5.9G Jan 11 11:37 /tmp/tmp.5uuhYWqqQT srap57dxr1:/# ls -lh /tmp/tmp.5uuhYWqqQT ls: cannot access '/tmp/tmp.5uuhYWqqQT': No such file or directory srap57dxr1:/# du -sh /data/guru/containers/ 1.1G /data/guru/containers/ How can I get more messages about the failing process? matthias
On Wed, Jan 10, 2024 at 9:33 AM Matthias Apitz <guru@unixarea.de> wrote:
I have an image on RH 8.x which runs fine (containing a SuSE SLES and PostgreSQL server):
$ podman images REPOSITORY TAG IMAGE ID CREATED SIZE localhost/suse latest c87c80c0911a 26 hours ago 6.31 GB registry.suse.com/bci/bci-base 15.4 5bd0e4152d92 2 weeks ago 123 MB
I created a connection to another host as:
$ podman system connection list Name URI Identity Default srap57 ssh:// apitzm@srap57dxr1.dev.xxxxxx.org:22/run/user/200007/podman/podman.sock true
To the other host I can SSH fine based on RSA public/private keys and podman is installed there to:
$ ssh apitzm@srap57dxr1.dev.xxxxxx.org Last login: Wed Jan 10 14:05:12 2024 from 10.201.64.28 apitzm@srap57dxr1:~> podman version Client: Podman Engine Version: 4.7.2 API Version: 4.7.2 Go Version: go1.21.4 Built: Wed Nov 1 13:00:00 2023
When I now copy over the image with:
$ podman image scp c87c80c0911a srap57::
it transfers the ~6 GByte (I can see them in /tmp as a big tar file of tar files) and at the end it says:
... Writing manifest to image destination $
(i.e. the shell prompt is there again)
But on srap57dxr1.dev.xxxxxx.org I can't see anything of the image at the end.
What I've done wrong?
Thanks
matthias
-- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
I am not at war with Russia. Я не воюю с Россией. Ich bin nicht im Krieg mit Russland. _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
-- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub I am not at war with Russia. Я не воюю с Россией. Ich bin nicht im Krieg mit Russland.
Is /tmp big enough to receive the image ? JB - On Thu, Jan 11, 2024 at 11:48 AM Matthias Apitz <guru@unixarea.de> wrote:
El día miércoles, enero 10, 2024 a las 10:09:27 -0500, Charlie Doern escribió:
You should also usually get some sort of:
Storing signaturesLoaded image(s):
after
Writing manifest to image destination
if this doesn't show up, then the image doesn't actually get stored. I remember there being some compatibility issues over certain types/sizes of images w/ scp. Can you throw a `-v` in there to see if it tells you anything else?
I did tests in two directions:
1) On the source host I run:
$ podman run -it docker.io/library/busybox
which gave me a local additional image and I transfered this to the target host:
$ podman images REPOSITORY TAG IMAGE ID CREATED SIZE localhost/suse latest c87c80c0911a 46 hours ago 6.31 GB registry.suse.com/bci/bci-base 15.4 5bd0e4152d92 2 weeks ago 123 MB docker.io/library/busybox latest 9211bbaa0dbd 3 weeks ago 4.5 MB
$ podman image scp 9211bbaa0dbd srap57:: Copying blob 82ae998286b2 done Copying config 9211bbaa0d done Writing manifest to image destination Loaded image: sha256:9211bbaa0dbd68fed073065eb9f0a6ed00a75090a9235eca2554c62d1e75c58f
i.e. this was transfered fine and shows up on the target host as:
srap57dxr1:~> podman images REPOSITORY TAG IMAGE ID CREATED SIZE <none> <none> b677170ada05 3 minutes ago 1.89 GB registry.suse.com/bci/bci-base 15.4 5bd0e4152d92 2 weeks ago 123 MB <none> <none> 9211bbaa0dbd 3 weeks ago 4.49 MB
apitzm@srap57dxr1:~> podman run -t 9211bbaa0dbd / #
2)
I copied over the files to build the image to the target host:
apitzm@srrp02dxr1:~$ scp -rp suse srap57dxr1:. Dockerfile 100% 5051 1.2MB/s 00:00 initSunRise.sh 100% 953 314.2KB/s 00:00 postgresql.conf 100% 29KB 5.0MB/s 00:00 testdb.dmp.gz 100% 388MB 110.0MB/s 00:03 keyFile 100% 893 63.2KB/s 00:00
and built the image there with:
apitzm@srap57dxr1:~> podman build -t suse suse ... which worked also fine: ... STEP 58/59: ENTRYPOINT /usr/local/bin/start.sh --> 86dab7ac3e4d STEP 59/59: STOPSIGNAL SIGQUIT COMMIT suse --> a1ffb1f71791 Successfully tagged localhost/suse:latest a1ffb1f717911b4e11aaa89d94c4959562c625b0e203dd906797e60d019cde57
The big difference between the image 'docker.io/library/busybox' and mine is the size (4,5 MB ./. 6,1 GB). When I scp my big image I see in /tmp that the sftp-server writes there a temp. file as:
ls -lh /tmp/tmp.RLHbJp9uzq -rw------- 1 apitzm apitzm 5.8G Jan 11 10:58 /tmp/tmp.RLHbJp9uzq
and when this reached the size of 6 GB it gets deleted
3) I removed all container files on the target host:
srap57dxr1:/ # rm -rf /data/guru/containers/* srap57dxr1:/ # du -sh /data/guru/containers/ 1.0K /data/guru/containers/
and started a fresh scp:
$ podman image scp c87c80c0911a srap57:: ... Copying blob a5a080851ed7 done Copying blob 6fc7ff0cb132 done Copying config c87c80c091 done Writing manifest to image destination
When the transfer has ended on the target host one can see 1. the big file in /tmp gets deleted 2. something was written below the area of the containers (which was empty before):
srap57dxr1:/# ls -lh /tmp/tmp.5uuhYWqqQT -rw------- 1 apitzm apitzm 4.3G Jan 11 11:35 /tmp/tmp.5uuhYWqqQT srap57dxr1:/# ls -lh /tmp/tmp.5uuhYWqqQT -rw------- 1 apitzm apitzm 5.9G Jan 11 11:37 /tmp/tmp.5uuhYWqqQT srap57dxr1:/# ls -lh /tmp/tmp.5uuhYWqqQT ls: cannot access '/tmp/tmp.5uuhYWqqQT': No such file or directory srap57dxr1:/# du -sh /data/guru/containers/ 1.1G /data/guru/containers/
How can I get more messages about the failing process?
matthias
On Wed, Jan 10, 2024 at 9:33 AM Matthias Apitz <guru@unixarea.de> wrote:
I have an image on RH 8.x which runs fine (containing a SuSE SLES and PostgreSQL server):
$ podman images REPOSITORY TAG IMAGE ID CREATED SIZE localhost/suse latest c87c80c0911a 26 hours ago 6.31 GB registry.suse.com/bci/bci-base 15.4 5bd0e4152d92 2 weeks ago 123 MB
I created a connection to another host as:
$ podman system connection list Name URI Identity Default srap57 ssh:// apitzm@srap57dxr1.dev.xxxxxx.org:22/run/user/200007/podman/podman.sock true
To the other host I can SSH fine based on RSA public/private keys and podman is installed there to:
$ ssh apitzm@srap57dxr1.dev.xxxxxx.org Last login: Wed Jan 10 14:05:12 2024 from 10.201.64.28 apitzm@srap57dxr1:~> podman version Client: Podman Engine Version: 4.7.2 API Version: 4.7.2 Go Version: go1.21.4 Built: Wed Nov 1 13:00:00 2023
When I now copy over the image with:
$ podman image scp c87c80c0911a srap57::
it transfers the ~6 GByte (I can see them in /tmp as a big tar file of tar files) and at the end it says:
... Writing manifest to image destination $
(i.e. the shell prompt is there again)
But on srap57dxr1.dev.xxxxxx.org I can't see anything of the image at
the
end.
What I've done wrong?
Thanks
matthias
-- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
I am not at war with Russia. Я не воюю с Россией. Ich bin nicht im Krieg mit Russland. _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
-- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
I am not at war with Russia. Я не воюю с Россией. Ich bin nicht im Krieg mit Russland. _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
El día jueves, enero 11, 2024 a las 01:18:33 +0100, Jean-Baptiste Ciccolella escribió:
Is /tmp big enough to receive the image ?
JB
I was already digging into this: /tmp is not big enough and I was looking how to change the location to where sftp-server puts the data. matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub I am not at war with Russia. Я не воюю с Россией. Ich bin nicht im Krieg mit Russland.
I'm not 100% sure of this but scp doesn't create temporary files during file transfer. I have no idea what podman does under the hood when you run your command but it reminds me how rsync works. It's not the best way to move an image to another server but why don't you *podman save*, *scp *the image then *podman load *on the remote server ? JB - On Thu, Jan 11, 2024 at 2:06 PM Matthias Apitz <guru@unixarea.de> wrote:
El día jueves, enero 11, 2024 a las 01:18:33 +0100, Jean-Baptiste Ciccolella escribió:
Is /tmp big enough to receive the image ?
JB
I was already digging into this: /tmp is not big enough and I was looking how to change the location to where sftp-server puts the data.
matthias
-- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
I am not at war with Russia. Я не воюю с Россией. Ich bin nicht im Krieg mit Russland.
It seems you can't change it. podman/pkg/domain/utils/scp.go at main · containers/podman (github.com) <https://github.com/containers/podman/blob/main/pkg/domain/utils/scp.go#L214> podman invokes mktemp on the remote server and that's where it sends the image. Thinking of it, it's logical. You don't really want to keep a copy of the image... /tmp is used for that purpose. What's wrong is that it doesn't catch (or report) the error. You should create an issue about that. JB - On Thu, Jan 11, 2024 at 3:09 PM Jean-Baptiste Ciccolella < jeanbaptiste.ciccolella@gmail.com> wrote:
I'm not 100% sure of this but scp doesn't create temporary files during file transfer. I have no idea what podman does under the hood when you run your command but it reminds me how rsync works.
It's not the best way to move an image to another server but why don't you *podman save*, *scp *the image then *podman load *on the remote server ?
JB
-
On Thu, Jan 11, 2024 at 2:06 PM Matthias Apitz <guru@unixarea.de> wrote:
El día jueves, enero 11, 2024 a las 01:18:33 +0100, Jean-Baptiste Ciccolella escribió:
Is /tmp big enough to receive the image ?
JB
I was already digging into this: /tmp is not big enough and I was looking how to change the location to where sftp-server puts the data.
matthias
-- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
I am not at war with Russia. Я не воюю с Россией. Ich bin nicht im Krieg mit Russland.
El día Thursday, January 11, 2024 a las 03:35:53PM +0100, Jean-Baptiste Ciccolella escribió:
It seems you can't change it. podman/pkg/domain/utils/scp.go at main · containers/podman (github.com) <https://github.com/containers/podman/blob/main/pkg/domain/utils/scp.go#L214> podman invokes mktemp on the remote server and that's where it sends the image. Thinking of it, it's logical. You don't really want to keep a copy of the image... /tmp is used for that purpose.
I was expecting to be able to define the remote temporary directory to overcome limits on the remote host.
What's wrong is that it doesn't catch (or report) the error. You should create an issue about that.
Here we go: https://github.com/containers/podman/issues/21239 matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub I am not at war with Russia. Я не воюю с Россией. Ich bin nicht im Krieg mit Russland.
On 2024-01-11 06:35, Jean-Baptiste Ciccolella wrote:
It seems you can't change it. podman/pkg/domain/utils/scp.go at main · containers/podman (github.com) <https://github.com/containers/podman/blob/main/pkg/domain/utils/scp.go#L214>
What happens if you: "echo TMPDIR=/var/tmp >> ~/.ssh/environment" and then try to copy the image?
El día viernes, enero 12, 2024 a las 10:34:58 -0800, Gordon Messmer escribió:
On 2024-01-11 06:35, Jean-Baptiste Ciccolella wrote:
It seems you can't change it. podman/pkg/domain/utils/scp.go at main · containers/podman (github.com) <https://github.com/containers/podman/blob/main/pkg/domain/utils/scp.go#L214>
What happens if you: "echo TMPDIR=/var/tmp >> ~/.ssh/environment" and then try to copy the image?
$ cat ~/.ssh/environment TMPDIR=/home/apitzm/.local/share/containers/tmp The env var is not published to the sshd and sftp-server processes: srap57dxr1:/home/guru # pstree -p 28910 sshd(28910)───sshd(28913)───sftp-server(28914) srap57dxr1:/home/guru # tr '\0' '\n' < /proc/28910/environ | grep TMP srap57dxr1:/home/guru # tr '\0' '\n' < /proc/28914/environ | grep TMP and the temp. file gets created in /tmp -rw------- 1 apitzm apitzm 255459328 Jan 15 07:59 tmp.F9prxDvQgw I freed space in the partition where also /tmp is located and the transfer of the image went fine: $ podman image scp c87c80c0911a srap57:: ... Copying blob 6fc7ff0cb132 done Copying config c87c80c091 done Writing manifest to image destination Loaded image: sha256:c87c80c0911a54c7bee8b15d494d336de93c233b2c87ff04813bc3a6fb5c2f47 On the target host 'srap57dxr1' the image shows as: srap57dxr1:~> podman images REPOSITORY TAG IMAGE ID CREATED SIZE <none> <none> c87c80c0911a 5 days ago 6.31 GB and starts fine: srap57dxr1:~> podman run -p 2022:22 c87c80c0911a Starting PostgreSQL: ok Is it intention that the REPOSITORY and TAG information are not transferred from the source: $ podman images REPOSITORY TAG IMAGE ID CREATED SIZE localhost/suse latest c87c80c0911a 5 days ago 6.31 GB registry.suse.com/bci/bci-base 15.4 5bd0e4152d92 3 weeks ago 123 MB docker.io/library/busybox latest 9211bbaa0dbd 3 weeks ago 4.5 MB Thanks matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub I am not at war with Russia. Я не воюю с Россией. Ich bin nicht im Krieg mit Russland.
On 2024-01-14 23:19, Matthias Apitz wrote:
The env var is not published to the sshd and sftp-server processes:
That was my mistake... PermitUserEnvironment is disabled by default. https://github.com/openssh/openssh-portable/blob/master/sshd_config#L94
El día domingo, enero 14, 2024 a las 11:33:30 -0800, Gordon Messmer escribió:
On 2024-01-14 23:19, Matthias Apitz wrote:
The env var is not published to the sshd and sftp-server processes:
That was my mistake... PermitUserEnvironment is disabled by default.
https://github.com/openssh/openssh-portable/blob/master/sshd_config#L94
I've modified the sshd config to: srap57dxr1:~ # grep PermitUser /etc/ssh/sshd_config #PermitUserEnvironment no PermitUserEnvironment yes and restarted the sshd; the temp. file remains below /tmp. Are you sure that 'podman' runs the normal ssh-client and sends the environment to the remote ssh-daemon? When the transfer is in progress and the remote temp. file is growing, I only see: $ pstree -p 429732 podman(429732)-+-{podman}(429733) |-{podman}(429734) |-{podman}(429735) |-{podman}(429736) |-{podman}(429737) |-{podman}(429738) |-{podman}(429739) `-{podman}(430124) matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub I am not at war with Russia. Я не воюю с Россией. Ich bin nicht im Krieg mit Russland.
El día lunes, enero 15, 2024 a las 09:57:16 +0100, Matthias Apitz escribió:
El día domingo, enero 14, 2024 a las 11:33:30 -0800, Gordon Messmer escribió:
On 2024-01-14 23:19, Matthias Apitz wrote:
The env var is not published to the sshd and sftp-server processes:
That was my mistake... PermitUserEnvironment is disabled by default.
https://github.com/openssh/openssh-portable/blob/master/sshd_config#L94
I've modified the sshd config to:
srap57dxr1:~ # grep PermitUser /etc/ssh/sshd_config #PermitUserEnvironment no PermitUserEnvironment yes
...
This was my fault now. The file ~/.ssh/environmment must be set on the server side to make it working. With this sftp-server writes the temp. file into the specified directory. It remains as a podman bug, that ENOSPC is silently ignored. I will make a comment in https://github.com/containers/podman/issues/21239 Thanks matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub I am not at war with Russia. Я не воюю с Россией. Ich bin nicht im Krieg mit Russland.
On 2024-01-15 01:48, Matthias Apitz wrote:
It remains as a podman bug, that ENOSPC is silently ignored. I will make a comment inhttps://github.com/containers/podman/issues/21239
https://github.com/containers/podman/pull/21304 doesn't fix that bug, per se, but it does provide users the ability to specify TMPDIR on the destination.
participants (4)
-
Charlie Doern -
Gordon Messmer -
Jean-Baptiste Ciccolella -
Matthias Apitz