From: "Adolf Belka (ipfire)" <ahb.ipfire@gmail.com>
To: development@lists.ipfire.org
Subject: Re: [PATCH 1/2] sshfs: Update to 3.7.1
Date: Sat, 09 Jan 2021 15:55:36 +0100 [thread overview]
Message-ID: <ba60857d-2cdd-3180-8d72-ec973c66bfac@gmail.com> (raw)
In-Reply-To: <BC5E4740-8AF7-4C42-9119-BCAA07D31F3B@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 6120 bytes --]
Hi,
On 07/01/2021 14:53, Michael Tremer wrote:
> Hello,
>
>> On 7 Jan 2021, at 13:34, Adolf Belka <ahb.ipfire(a)gmail.com> wrote:
>>
>> Hi Michael,
>>
>> On 07/01/2021 12:25, Michael Tremer wrote:
>>> Hi,
>>> In the Git repository of fuse, there is an initscript that loads the kernel module when the system boots:
>>> https://github.com/libfuse/libfuse/blob/f54eb86e9a0b596dfeceb18277efa8f840d85919/util/init_script
>>> Maybe we want to integrate this.
>> That could be an option but the downside would be that the fuse module would then be enabled for all IPFire users, even if they are not using fuse. I think if people aren't using fuse on a firewall it is probably better to not load it automatically.
> Yes, I would agree. I assumed fuse was a package. Maybe it should be one.
So I have had a look at this and it seems like both sshfs and fuse could
be converted to addons. Fuse is only mentioned on three other addons,
samba, openvmtools and borgbackup and not for any core programs.
Fuse would need to be added as a dependency to those addons. By having
that dependency does it mean that any systems with one of those addons
already installed will automatically have the fuse addon installed as
part of the core update or will I need a separate script to check for that.
Should I look at doing this change now or wait till after the next core
update has been released.
Regards,
Adolf
>> As there have been no questions on IPFire Community about fuse not being loaded or any problems with sshfs then either no one is using sshfs and fuse or they have been able to figure it out.
>>
>> My preference would be to leave it as it is.
>> I was going to say that I could update the wiki to mention about the need to run modprobe fuse but I found that sshfs is not mentioned anywhere in the wiki (at least the search came back with zero results).
>>
>> Having found out about sshfs on IPFire, I will likely use it from time to time.
> It is quite a nice tool :)
>
>> Regards,
>> Adolf
>>
>>> -Michael
>>>> On 6 Jan 2021, at 19:21, Adolf Belka <ahb.ipfire(a)gmail.com> wrote:
>>>>
>>>> Hi Michael,
>>>>
>>>> I suddenly thought I should also check the old version on Core 153, so I did that and the same thing happens. The fuse module is not loaded automatically when sshfs command is run, but the error message is very helpful.
>>>>
>>>> "fuse: device not found, try 'modprobe fuse' first"
>>>>
>>>> So the new sshfs version operates the same as the old one, so I am no longer so worried about this.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Adolf
>>>>
>>>> On 06/01/2021 19:39, Adolf Belka wrote:
>>>>> Hi,
>>>>>
>>>>>
>>>>> On 06/01/2021 16:30, Michael Tremer wrote:
>>>>>> Hi,
>>>>>>
>>>>>>> On 5 Jan 2021, at 14:28, Adolf Belka <ahb.ipfire(a)gmail.com> wrote:
>>>>>>>
>>>>>>> Dear all,
>>>>>>>
>>>>>>> Forgot to mention in the logs that I have also installed the built IPFire with new fuse and sshfs into my testbed system and was able to setup an sshfs mount from a remote computer into the IPFire system, so confirmed working.
>>>>>>>
>>>>>>> The only thing I had to do was run modprobe fuse as the fuse module was not loaded. Is that normal to need to do or did I miss something when I was building sshfs/fuse
>>>>>> I would expect that sshfs is doing that automatically.
>>>>> Then there may be a problem. When I ran the sshfs command I got a message that it could not find fuse and it suggested that I should run modprobe fuse, which I did, and then the same sshfs command worked.
>>>>>
>>>>> Not sure how to find out why sshfs did not have the modprobe command run automatically or how to make it do so.
>>>>>
>>>>>>> Regards,
>>>>>>> Adolf.
>>>>>>>
>>>>>>> On 05/01/2021 15:20, Adolf Belka wrote:
>>>>>>>> - Update sshfs from 2.2 to 3.7.1
>>>>>>>> - Changelog is available at https://github.com/libfuse/sshfs/releases
>>>>>>>> - Build had to be changed from autotools to meson/ninja
>>>>>>>> - Change in rootfiles
>>>>>>>> Signed-off-by: Adolf Belka <ahb.ipfire(a)gmail.com>
>>>>>>>> ---
>>>>>>>> config/rootfiles/common/sshfs | 2 ++
>>>>>>>> lfs/sshfs | 14 ++++++--------
>>>>>>>> 2 files changed, 8 insertions(+), 8 deletions(-)
>>>>>>>> diff --git a/config/rootfiles/common/sshfs b/config/rootfiles/common/sshfs
>>>>>>>> index 2cafa3e24..579b938f5 100644
>>>>>>>> --- a/config/rootfiles/common/sshfs
>>>>>>>> +++ b/config/rootfiles/common/sshfs
>>>>>>>> @@ -1,2 +1,4 @@
>>>>>>>> usr/bin/sshfs
>>>>>>>> +#usr/sbin/mount.fuse.sshfs
>>>>>>>> +#usr/sbin/mount.sshfs
>>>>>>>> #usr/share/man/man1/sshfs.1
>>>>>>>> diff --git a/lfs/sshfs b/lfs/sshfs
>>>>>>>> index 23fbd18ca..1e7706194 100644
>>>>>>>> --- a/lfs/sshfs
>>>>>>>> +++ b/lfs/sshfs
>>>>>>>> @@ -24,10 +24,10 @@
>>>>>>>> include Config
>>>>>>>> -VER = 2.2
>>>>>>>> +VER = 3.7.1
>>>>>>>> -THISAPP = sshfs-fuse-$(VER)
>>>>>>>> -DL_FILE = $(THISAPP).tar.gz
>>>>>>>> +THISAPP = sshfs-$(VER)
>>>>>>>> +DL_FILE = $(THISAPP).tar.xz
>>>>>>>> DL_FROM = $(URL_IPFIRE)
>>>>>>>> DIR_APP = $(DIR_SRC)/$(THISAPP)
>>>>>>>> TARGET = $(DIR_INFO)/$(THISAPP)
>>>>>>>> @@ -40,7 +40,7 @@ objects = $(DL_FILE)
>>>>>>>> $(DL_FILE) = $(DL_FROM)/$(DL_FILE)
>>>>>>>> -$(DL_FILE)_MD5 = 26e9206eb5169e87e6f95f54bc005a4f
>>>>>>>> +$(DL_FILE)_MD5 = 22ac23d05ca7c56fb568627f086374d0
>>>>>>>> install : $(TARGET)
>>>>>>>> @@ -72,9 +72,7 @@ $(subst %,%_MD5,$(objects)) :
>>>>>>>> $(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects))
>>>>>>>> @$(PREBUILD)
>>>>>>>> - @rm -rf $(DIR_APP) && cd $(DIR_SRC) && tar zxf $(DIR_DL)/$(DL_FILE)
>>>>>>>> - cd $(DIR_APP) && ./configure --prefix=/usr
>>>>>>>> - cd $(DIR_APP) && make $(MAKETUNING)
>>>>>>>> - cd $(DIR_APP) && make install
>>>>>>>> + @rm -rf $(DIR_APP) && cd $(DIR_SRC) && tar axf $(DIR_DL)/$(DL_FILE)
>>>>>>>> + cd $(DIR_APP) && meson --prefix=/usr builddir && cd builddir && ninja && ninja install
>>>>>>>> @rm -rf $(DIR_APP)
>>>>>>>> @$(POSTBUILD)
next prev parent reply other threads:[~2021-01-09 14:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-05 14:20 Adolf Belka
2021-01-05 14:28 ` Adolf Belka
2021-01-06 15:30 ` Michael Tremer
2021-01-06 18:39 ` Adolf Belka
2021-01-06 19:21 ` Adolf Belka
2021-01-07 11:25 ` Michael Tremer
2021-01-07 13:34 ` Adolf Belka
2021-01-07 13:53 ` Michael Tremer
2021-01-09 14:55 ` Adolf Belka (ipfire) [this message]
2021-01-09 14:58 ` Michael Tremer
2021-01-09 15:23 ` Adolf Belka (ipfire)
2021-01-06 15:22 ` Michael Tremer
2021-01-06 18:36 ` Adolf Belka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ba60857d-2cdd-3180-8d72-ec973c66bfac@gmail.com \
--to=ahb.ipfire@gmail.com \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox