esbeeb

Members
  • Content Count

    67
  • Joined

  • Last visited

About esbeeb

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. There's a cheap M2 SSD, for example for sale here, but it would be a bad idea to use it in any ARM board with an M2 drive slot. I have one of these M2 drives in my laptop, and I learned the hard way how slow it will get within 1 year's use, like 30MB/sec read, 8.5 MB/sec write! Over time, this drive will gradually go slower and slower and slower, until you figure out you need a firmware upgrade. Then you'll need to use the closed-source firmware-upgrading CLI utility that Micron publishes. There is a version for linux, but it's AMD64 only. You might think you can put the M2 drive in a USB-3.0 enclosure, then firmware upgrade it in that enclosure. No, you can't, the firmware upgrader will only work if the M2 drive is installed in an M2 slot on the mobo. See here for more details.
  2. I've been suspicious that my TP-Link UE300 GbE dongle is sort of slow. I've got a new GbE dongle, to compare with, an Anker AH212. loading 2GB THe Anker goes a bit faster than the TP-Link, for FTP and SMB, but not by much: Uploading 2GB of tiny ebooks (2029 files in 756 folders): - TP-Link: - FTP: 22.3 MB/sec. - SMB: 12.0 MB/sec - Anker: - FTP: 25.0 MB/sec - SMB: 14.6 MB/sec So basically, all my tests above are quite trustworthy, I think. With a more carefully chosen GbE dongle, you only get a couple more MB/sec.
  3. Word to the wise: use brand-new USB 2.0 A-to-B cables (printer cables) within those cylindrical inline magnets on the wire (which clean up electrical interference). I had "UAS inflight" errors (and checksums were failing on BTRFS scrubs) until I changed these USB cables accordingly. In the future, if I ever make any other NAS, I'll never use USB to attach any "permanent" drive (which will have either the OS on it, or have a file share served from it). USB might be OK for some temporarily-attached drive or stick, where a one-off backup is made (say, for making periodic, "off-site" backups). The slightly higher cost to have proper SATA connections is so well worth it, I say (even if on an 8-year old, used PC, that's still in good running condition.) Cheaping out, and depriving yourself of enough SATA ports is a very bad idea, to save a small amount of money, IMHO.
  4. I, for one, will patiently wait for Debian to do that backporting. Or wait until Buster is released. Whichever will come first. I have enough on my plate already.
  5. There's still no security fix yet for the proftpd currently in Debian stable, and Debian agrees proftpd 1.3.5d upstream does contain the fix.
  6. esbeeb

    New administrator

    Yay, @lanefu!
  7. They had me file a bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923926
  8. I just emailed Debian security, informing them of the DOS Attack.
  9. The way I see it, all these ARM development boards always show up on the market in a highly immature state (with respect to software support in linux, and all associated layers above the kernel). Indeed, they are a playground for Linux developers, and are thus called development boards. I don't see how Armbian, or any other project like Armbian (like say, DietPi) could ever hope to reach "non-playground mode", considering that all boards arriving onto the market take huge efforts, one board at a time, to smooth all the rough edges. That can be so very time consuming, that it's no surprise that the Armbian project, as a whole, doesn't ripen in all the other ways that we might like. I for one, do not blame Igor, for the horrifically unpolished state (Linux software-wise) that new ARM development boards are "born with" on the market. Each new board, which this project decides to take seriously, dumps a huge burden onto this community. I, for one, would like to suggest that boards coming from vendors who have track records of creating a lot of development work to get polished, should not be included in Armbian, no matter how sweet the tech specs look, and no matter how low the price is. Even if just a handful of boards are works-in-progress or supported, from a more benevolent, Linux-friendly vendor, I call that options enough. So in summary, I say, support fewer, more sane boards! Quit trying to support a wide range of boards that are too large a nightmare to tackle. Sure, list those "nightmare" boards, but then just say underneath "too big a nightmare for Armbian to develop for". That will send a message back to the vendors to make their boards, and linux software offerings, more sane. @Igor, which 10 Armbian-supported/WIP boards would you say are the biggest nightmares to support? Which vendors are the worst for making software development hassles? Maybe just halt all development efforts on those. Sure, many people might grumble, but once they get over it, they can fork out $100 or whatever to just buy some newer, better board which is much easier for Armbian to support, and "get back in the game" again.
  10. Agree strongly. @tkaiser, you're technical expertise is clearly very well developed, and is an asset to this community, but some diplomacy and gentle speech will go a long way towards everyone getting along on this forum. Getting along is very important if Armbian and Linux in general is to grow as strong as we would all like it to, longer term, especially as it moves rapidly towards a more prime-time audience who want and expect to see a polished act. So let's not over-react here. Harsh speech doesn't help. I looked for a debian backport of proftpd. Unfortunately, there isn't one that I could find. I can live with this problem for now, it's no show stopper. I still have SMB working decently well in OpenMediaVault, and I can just turn off the FTP server as a workaround. I'm just about to go for a week's vaction, and I'll see what may have transpired here when I return. Sorry, I don't have the time or energy right now to go through Debian's formal procedure to file a security vulnerability report (which I feel is the best and most proper solution). If someone else would like to do that, I would really appreciate it. I also don't have time to send a report upstream to the OpenMediaVault project either, who might not see this thread. Debian is a very conservative distro, but at least they do backport fixes to Security Vulnerabilities. I think they are the first resort to a solution, which would then trickle downstream to us. I'm personally glad Armbian is based on Debian, and I probably wouldn't have picked Armbian in the first place (as my go-to distro for non-Raspberry Pi ARM boards), if it weren't Debian-based. I forgive Armbian from having to do many hacks behind to scenes to make it work, because I know what a hairball the Linux experience tends to be on all the wild and crazy and diverse ARM development boards, no matter which way you try to approach it.
  11. This might be fixed in proftpd version 1.3.5d. Note the current version in Armbian is still 1.3.5b.
  12. Here's how to re-create the memory leak. You need to FTP in a large folder, with many tiny files. The 60 GB folder I'm trying to upload contains about 40k files. There are also many, many sub-folders, and sub-sub-folders, over 12k. My NanoPi Neo crashes after uploading less than 13GB of the 60GB (when SSL is enabled on the FTP). I enabled SSL for FTP using the features provided by OpenMediaVault (within the OpenMediaVault web admin interface). I similarly used entirely default settings for the FTP server, other than enabling SSL. I believe this could rightfully be called a "denial of service", as in, a security vulnerability. A malicious user, who had a valid username and password into the FTP server (even if just an anonymous user, if allowed), merely needs to upload a "Calibre Library" folder, containing a bunch of small ebooks, larger than 13GB in size, to cause the server to a freeze. Am I the first to discover this? Probably not.
  13. I've figured out what causes part of the memory leak. When SSL is disabled for the FTP server (within Openmediavault, which I had enabled at first), then there will still be a memory leak, but just not as fast. Yes, that means two memory leaks! ProFTPd just leaks all the faster when you have SSL turned on. With non-SSL encrypted FTP transfers, the memory is still leaking, just much slower. As the RAM usage slowly creeps up, at a rate of about 1MB every 5 seconds, my 60GB file upload might actually make it across, before all the RAM runs out. Boo, proftpd!! I'll see about opening a bug later...
  14. I did an apt-get update and apt-get upgrade, and rebooted. This set the vm.swappiness to 100. Here is new armbianmonitor -u output, during ftp transfer: http://ix.io/1BJA Note, current version of proftpd-basic installed is 1.3.5b-4, as well as proftpd-mod-vroot, version 0.9.4-1. As I watch htop, here's what I observe, during an FTP upload. The normal RAM (never mind zram) starts off having only 128M being occupied. As the FTP transfer progresses, the RAM usage counts up and up and up, over several minutes, in a very linear and gradual way, with proftpd as the top process. The RAM just keeps slowly filling, at a rate of about 1MB/second, until all the RAM runs out, and then a crash! It looks like a memory leak somehow in either proftpd-basic or proftpd-mod-vroot!! Activity happens a lot in /var/log/proftpd/vroot.log during the FTP transfer, looking like the following: 2019-02-22 09:22:51,284 mod_vroot/0.9.4[2252]: found 0 VRootAliases in directory '/srv/dev-disk-by-id-usb-JMicron_Tech_00000000522A-0-0-part1/share2/somefolder1 2019-02-22 09:22:51,470 mod_vroot/0.9.4[2252]: found 0 VRootAliases in directory '/srv/dev-disk-by-id-usb-JMicron_Tech_00000000522A-0-0-part1/share2/somefolder2 I think the zram thing is a red-herring now. It would clearly all get full, no matter how I fine tune it. I've changed the title accordingly. Accordingly, I never edited /etc/default/armbian-zram-config. @tkaiser, the reason I use FTP for larger transfers, is that it's faster than SMB. I get about an extra 10MB/sec using FTP, rather than SMB, over GbE. I do use SMB by default (in Nemo), for smaller transfers (say, anything less than about 300 MB), and just surfing around file shares, maybe streaming a video or MP3.
  15. (Edit: it's a red herring for me to worry about swap. Please see a few posts down...) Hello. My NanoPi Neo 2 only has 512MB RAM. I'm using it for OpenMediaVault. It starts swapping very badly (totally paralysing it) when I FTP 60GB worth of tiny files into an attached 500GB SSD SATA drive (attached with the NAS kit). Yes, ProFTPd is RAM-hungry! I know how to create and work with traditional linux swap files. I'm a noob to this whole zram thing, which I suspect is more trouble than it's worth. I would prefer to not use zram, and use a traditional swap file on an attached 6TB 3.5" SATA drive (attached over USB 2.0 with UAS). It's a backup drive that sits there all day long doing nothing, in fact it goes to sleep all day (and only wakes up in the middle of the night to do a backup). zramctl shows: NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lzo 60.3M 4K 78B 12K 4 [SWAP] /dev/zram1 lzo 60.3M 4K 78B 12K 4 [SWAP] /dev/zram2 lzo 60.3M 4K 78B 12K 4 [SWAP] /dev/zram3 lzo 60.3M 4K 78B 12K 4 [SWAP] Those zram device files are on my Sandisk Ultra MicroSD card (which is "A1"), where Armbian runs from. My lightly-used SATA drive would be better for me, for running a traditional swap file from (due to its just sleeping all day otherwise). Is there some way to tell my Armbian "quit with zram, and just use a traditional swap file, as per my /etc/fstab"? BTW: I've set my "vm.swappiness" to 5 in /etc/sysctl.conf