packages
packages copied to clipboard
openwrt
sftp-server: add package
sftp-server is a lightweight sftp-server which can be used if user wants to avoid -O when using scp and installing openssh-sftp-server. sftp-server can be used as a drop-in replacement for openssh-sftp-server while it isn't as feature rich.
sftp-server is also known as Green End sftpserver.
Package uses git instead of release/tag because tagged versions were quite out-dated. I also added some patches from forked repositories which either provide small fixes, for example, to autoconf script - or add features, such as socat support.
sftp-server is minimal comparing disk space needed by openssh-sftp-server. And it does not have depencies.
Maintainer: me Compile tested: x86_64, latest git Run tested: x86_64, latest git
Since it's possible a conflict when both OpenSSH and the GreenEnd are installed we we need to add to Makefile:
ALTERNATIVES:=100:/usr/lib/sftp-server:/usr/libexec/greenend-sftp-server
And similar to the OpenSSH SFTP package but with a higher prio:
ALTERNATIVES:=200:/usr/lib/sftp-server:/usr/libexec/sftp-server
Since it's possible a conflict when both OpenSSH and the GreenEnd are installed we we need to add to Makefile..
It's marked to conflict with openssh-sftp on line 27 of Makefile- Why would you install them both? If you can spare the disk space and want to install openssh's version, it has all the bells and whistles that this one has- so why would you install this as well? This is a minimal drop-in replacement, not competing software.
The conflict is even better, agree. Additionally it worth to rename the package to greenend-sftp-server to make a clear difference with the openssh-sftp-server. Although its author didn't specify the recommended package name the greenend sounds most precise.
@stokito
I am not sure about that and before doing so, I'd like to have a second opinion recommending so. It is quite clear to me that openssh sftp server is named as openssh-sftp-server - openssh has packages in "openssh" family. This is widely known just as sftp-server; that's how I found it when I searched for possible solutions to avoid using -O flag - without using openssh-sftp-server or toggling setting which accordingly to build root might cause incompatibilities. It depends on how you search for it in package manager; for example, if you use luci - with this name, you find it easier from the list, ofcourse there is search - and I use grep to search packages in console - but still, in my opinion, this name is more clearer to me and while I cannot talk in behalf of others - from this experience in finding it clearer with this name and how it's globally referred, I propose this name. And due to same experience, I didn't think your opinion is reasoned enough for me to just blindly follow it.
Also most url's refer it as just sftp-server, I already added that dash there to standardise naming. For example, it's repository isn't named greenend-sftp-server, nor is its website url, and for author - it would had been ridiculous to rename it. Prefix greenend also would make it more like a competing product with openssh's sftp server, which this is not - this is minimal/lightweight version, if I'd see it as greenend-sftp-server, that would definetly confuse me to think that it might be improved somehow from openssh's alternative. And title of package already let's you know that it's green end's version.
@1715173329 So for now, naming opinion is 1 to 1, so I'd like one more vote to either direction. Tianling, would you mind to give your final word on it?
Okay please calm down @stokito (just) made a suggestion ;)
I'm not an expert on naming, so for me both names are fine.
However, sftp-server might be more likely to suggest that it is a lightweight version.
I am sure that guys don't want to hear this, but I am pretty reluctant to have this merged. I hope you would not be offended by this, usually if someone is looking for sftp server, then the OpenSSH is the choice and adding some alternative might sound good, I don't think that multiple users will use it since these days routers are getting more hardware resources, because SW is getting huge. Also, this one is somewhere being labeled as experimental and the development is not exactly active.
In my view, all these things need to be taken into account.
I was almost certain that this (not necessarily green end) was included already. I frequently have to run scp -O, otherwise.
@oskarirauta what is the pkg file size of this? That's usually a very convincing argument. Smaller binaries = win.
| aarch64_generic | openssh-sftp-server | (greenend-)sftp-server |
|---|---|---|
| IPK size | ~ 62 KiB | ~ 28 KiB |
| Binary size | ~ 192 KiB | ~ 64 KiB |
Just because the package is smaller then it needs to be merged even though it is experimental? You need to see it from the bigger picture I would say. Why OpenSSH SFTP server is not sufficient? Once, this gets merged, maintainers needs to look at it, update it and all upstream and downstream distributions will download this, it will use hardware resources, increase the build time, etc. While I looked into the Git sources, I found it that it is one man project.
We should have some votes and not merge everything, because it is smaller and the expected value is not so big, because how many users will exactly download and use this package?
This is only opinion, I do not want to participate on a vote in anyway if possible. Where I look at this, I am not sure if I already regret bringing this here as it has already created so much arguments. As all are not against, is the only reason why I haven't closed this as rejected. Now to that honest opinion..
Advantages are size and no depencies. In any other way, OpenSHH surely is better. But I did not propose this as a replacement, I proposed it as a solution to avoid using -O when using scp, I hate that- and while this could be avoided in dropbear build time settings, it clearly states that it might cause compatibility issues so I looked for another solution. And that it covers perfectly. When possible, I also try to avoid using openssh, it is heavy, mostly in space it uses. I wouldn't say build time is issue. Or recource usage. Not as long as we have monstrosity called node.js - or openssh which is nothing when compared to node.js - build time for this... is next to nothing when you compare to those too. And what is wrong with one man projects? Projects with more people, often grow and become huge; like openwrt 😁 but when it is something simple and small that we are looking for... Do we need more than one man for that? Holy bible says “Reproduce and be fruitful! Populate the earth and subdue it! Reign over the fish of the sea, the birds of the air, and every creature that lives on earth.” - but it is not a task for one man. But for a family, more than one man... might end-up in worst case, with corpses. Most one man projects also accept contributions; if you have an idea of improvement, he surely will consider your PR if propose one. Then it wouldn't be a one man project. But if you have nothing to add... It will stay as a one man project.
@BKPepe Sometimes I think that you want to run OpenWRT down or to extinction; I am old, or atleast in my opinion I am, anyone pass 50 or 60, would dis-agree.. Change, for me, is due to that always a difficulty or un-tolerated (why -O maybe must be fixed on One way or another 😁) but yet, I don't see OpenWRT as a lesser distribution at all. Mine runs latest Weston accelerated if I want to (not started by default, for testing only), and yes, designed for routers, mine is a 8 port router, even while it is powered by Intel's i7. Please, try sometimes to think that glass is half full instead of half empty. That said, leave it to there and stick with what you said and reject this as that definetly seems like less work for me. Linux and freedom; idea behind all my contributions end with simple idea of helping others, giving a chance for others not to need to re-invent the wheel and to share. Maybe all that died when next generation born and it is no longer valued to participate in community. Like I said, I am a dinosaur; in the good age of internet, it was almost a perfect source of absolute intelligence when it now is more a source of false information, advertisement, scam and stealing money from people. On most forum's, answers to your questions are "why would you want to do that", "just buy this from store, even if it is plastic and runbish, it beats whatever you are trying to build" or "google it".. What once brought best characteristics of human race out- seems to these days bring out more the worse and people still living that era when everything was better.. Seem to be in a wrong place. Wow, sorry. I have a bad habbit of rambling, seems that I did it again and even gave opinion of everything instead of sticking to topic.
So more oppose to this than people who want this? Isn't that a reason for rejecting this and no official vote needed, because what vote would be more official and authentic than what we already had? Besides, administrator votes and opinions should be taken as expert opinions, so why to continue this. I perfectly understand why author did not want to change name of this, I also write my software from my own perspective even if someone else has a different point of view- so why should OpenWRT budge for something that clearly is stated as NACK when only random users are not against it? Anyone wanting this, can still download package as a patch as long as they find this PR and I have no desire to bring anything to this project this much of arguments for dis-agreement and sides. No voting, democracy sometimes is just a call for more arguments. Plain simple, vote between administrators only please, and whose vote is not present; does not count as more than empty. Thank you.
And for what it counts, currently only One vote is present, belonging to @BKPepe - so isn't it over with that?
For people that are not interested in sftp server, but use scp and are annoyed to use -O, this package is the solution (at least if minimal solution is searched). For people who need/want sftp server, I would recommend openssh's sftp server package. For people who do not use sftp server, who don't use scp or use -O fluently, I recommend to forget both packages.
For those who want it- you can get it from secondary package repo here or download a patch against packages repository from here - pre-built binaries are not made available, at least by me.
Nevertheless, contributor of this pull request considered merging of package as voted to opposed and cancelled request.
In @BKPepe's defence, he's pretty good at keeping packages in openwrt fairly tidy.
@systemcrash
I don't really care that much, anymore, just wanted to share something that for me, was a solution to issue- but I don't think openwrt couldn't live without, and that is shared with staff; so I closed it. It's in one of my private(while publicly available though) repositories anyway, so I have it, whether is was merged to mainstream or not. Attempted and rejected. Feel free to make your own PR on this if you want, but on my behalf, it's over.
I've noticed that- especially if software is written with C or C++. For quite some time ago, I decided that I do not try to convince him- instead close everytime as I don't want to/can't argue with him, it just leads to nothing, so better to fold early, since when he's made his mind, there's nothing that would make him change his mind - if someone does not find use for it, it doesn't mean that others wouldn't, that's propably why package was created in the first place.. It is often said by him that there's lack of contributors, but saying them that they wasted time and effort with vague arguments, often keeps them away and not coming back. I've thought several times to retire from this project and PR by PR, I am closer to it 😃 Already looking forward to my next rejection and early close of PR 😄
TBH I used to think openssh-sftp-server was big, and assumed that it would rely on openssl and other openssh utils. But this is not real, when I checked it, it's smaller than what I think, and it's also dependency-free.
On most OpenWrt devices, squashfs+jffs2/ubifs is used, so these binaries will be compressed, it means openssh-sftp-server will just take ~ 60-65 KiB, this is a reasonable size. Of course the (greenend-)sftp-server will save ~ 35 KiB, but it does have more potential problems, mainly maintenance issues and security issues. I think the days of the 4M SPI-NOR flash are over, at least on OpenWrt. The saved ~ 35 KiB sounds like a bonus, but it's not that important these days. IMO it's unlikely that someone would waste spaces for a sftp server on a size-sensitive device.
The above are my personal thoughts.