nars

Members
  • Content count

    355
  • Joined

  • Last visited

Community Reputation

0 Neutral

About nars

  • Rank
    Advanced Member
  • Birthday 02/02/83

Converted

  • Gender
    Male
  • Location
    Portugal
  1. just a quick note of something I did just noticed... if any of you guys are running vboxwebsrv manually with "--logfile /dev/null" param (as many suggested on a few old topics on this forum) you should always also add "--logrotate 0" else it rotates the /dev/null to /dev/null.1, etc... and creates a new /dev/null that it's actually a regular file on ramfs... like this: root@unRAID:~# ls -l /dev/null* -rw------- 1 root root 4093779968 2016-01-10 06:53 /dev/null -rw------- 1 root root 54991 2015-12-26 06:37 /dev/null.1 -rw------- 1 root root 157941 2015-12-25 19:58 /dev/null.2 -rw------- 1 root root 868 2015-11-30 00:43 /dev/null.3 crw-rw-rw- 1 root root 1, 3 2015-11-24 23:50 /dev/null.4 not good btw, think it doesn't affect current theone's plugin, as apparently he runs vbox using rc init script.
  2. In fact I think it was never fully fixed, or it got back again long time ago yet on last 5.x builds... it was mostly fixed... but I did also see it happening again sometimes... but I couldn't reproduce it when I wanted, that's why I did never posted about it... I guess it must happen depending of something that I don't know what it is... maybe when we do array changes... or... not sure really
  3. @bjp999/garycase: Thanks for your comments. I didn't want to take all these posts about such a small suggestion, as it was just that, a very small suggestion of a very simple thing... however I don't like to leave people without a reply and wanted to make sure you got my idea correctly... Again it was just a small suggestion, on a topic that limetech was apparently following, just that, if limetech finds it a good one or not it's with him... and I will accept his decision whatever it is. Again, I don't need an extra license, as I said above I own an extra spare license, that was never actually assigned to any GUID at all, I did purchased it just to support Tom and to keep it if I do ever need it... If the only way to run a tests version from now would be to use a license, then sure I will use it for that... however I just think it is makes no sense (or is fair even for some others) to require a license for that kind of usage (tests, development, ...), where we don't need any relevant storage amounts, etc... @garycase: I disagree with you when you say that was the purpose of the extra license, it wasn't. The purpose of the extra license was for tests (v6 betas) on systems with actual storage, and with a reasonable amount of HDD's... else Basic one would do it... right? my suggestion was to allow a minimal tests/development environment without allowing relevant storage amounts... very different thing... Just one last note, garycase, do you remember... right before 5.0 final being released, when I did found and reported the reiserfs issue that caused data corruption on hard reboot even long time after data written (then intensively tested by webootech, you, me, jonathanm...)? I wouldn't have found it without the tests I was doing on VM's... and I didn't owned an extra license at that time... think on that kindly -- Btw, I do also understand itimpi point for a cheaper license for 3 or 4 hdd's... why not? Many users will probably start with such amount of hdd's... later they will upgrade almost for sure... and anyway some other feature(s) could also be disabled on such cheaper license.
  4. Please don't get me bad, I have no issue at all with registering. I do think the new trial model is really good! New users will be able to fully test it for 30-days, perfect and I would not change that at all. My suggestion would be just an extra trial mode (if user doesn't register for the full trial mode) that would be far more restrictive (size limit, and eventually no virtualization...) but would run forever and not require GUID, then allowing to easily run such trial on anything, even VMWare/VBox VM's for testing etc... I can tell that I did myself always had a VMWare Workstation VM to test new unRaid beta versions, etc before installing them on real server and to compile new things (without the need to be installing dev tools on real server), etc, etc... I guess more people do similar things... surely it would make no sense to require an extra license (despite I actually own a spare one...) for such purposes as it would not be actual unRaid usage but something to be used from time to time when new unraid version available, or testing something, etc... also would make no sense to ask trial license extensions for such testing purposes... you see my idea? P.S. theone user on 1st page on this same topic describes the same problem, he seems to also use a testing environment on VBox for similar purposes as I do...
  5. @trurl: It was always possible to boot the FREE version without USB, with a FAT partition on an HDD... concerning the effort I would expect that being a simple thing for limetech to implement... else forget. @garycase: Indeed may be a true point! but then I do also ask myself if such virtualization features doesn't really work without being able to start the array? (i.e. without registering), anyway if that is the problem, then I think would be acceptable on such trial mode to prevent using virtualization features completely, most users needing such mode would be to run on a VM for tests then not requiring virtualization features for anything for sure...
  6. @limetech: Would it be possible to also get a size limited trial mode (even if limited to 20GB or something small...) IF user doesn't register for the 30-day trial? And that mode working even if no usb attached at all. Such mode would be useful for small test environments on VM's, etc... i.e. user would need to apply for registered trial to get rid of the size limits but then would have 30-day time limit, else he would be able to keep the size limited mode forever, for tests, etc... best of both worlds?
  7. It should not stop working on an actual version you are running on your server, since AFAIK no online check is made at all, currently... but you may find it blocked later when you update to a new version... if that happens I believe that contacting Limetech and explaining the problem it may get solved asking to move that license to a different flash drive guid, since the same seems usually also possible even when a flash drive dies... but not an officially granted thing.
  8. rick.p: sure it is unique? it appears realtek based like the Samsung I did posted above... try an 'lsusb' to get the full serial from it (shown as 'iSerial'), because serial it's often partial on unraid guid, missing some digits at left... then search the full serial on Google, if you can find it then it is not unique and despite not yet blocked it may get blocked on the future... I did found mine on usbflashspeed.com, they seem to list details of a lot of flash drives / card readers, guess they build db automatically from some speed test tool...
  9. Yes, I wanted to post what I had before people wasted money. I have a new solution I'm working on that should satisfy all parties. I'll post when unRAID 6 is released. Yes, unfortunately seems a PITA to find an usable one Will be waiting your solution, thanks
  10. @WeeboTech: Seems like my post waked you up Btw, One more to the NO list: Samsung Electronics 16GB EVO Micro SDHC with USB 2.0 Reader Class 10 Memory Card http://www.amazon.com/dp/B00JEVHZK4/ I own only one unit but did search on Google for it's serial and found it is not really unique, not even unique to these samsung readers apparently, the reader seems based on a realtek chip and there are a few other readers with same realtek chip and same same serial...
  11. One more for the no list: Transcend TS-RDP5W I did got hands on 2 units and both with same GUID.
  12. renaming files should not work, if I remember well I did tested that sometime ago... apparently installpkg relies on file extension and will just fail if not the matching compression...
  13. I'm not fully sure about details, but yes, at morning I did got in a situation that the only way to log into the server was ssh, telnet was just impossible to login until I closed some screen sessions. I can't find a limit on screen sessions, apparently... but seems that after some few are used telnet doesn't work anymore, not a problem for screen or ssh though. Edit: I did some quick testing with this again and found that indeed ssh and screen seems to have no problems to get sessions on something like pts/15, pts/16, etc... (and I didn't touched /etc/securetty), but telnet seems to really refuse connection if there is not a free pts/0 to pts/7, then a way to get fully "locked" from telnet (probably what happened to me at morning, and now again on my testing) is: - open a telnet/ssh session, it will get on pts/0 - open at least 7 screen sessions taking pts/1 to pts/7 - open a new telnet/ssh session, it will get on pts/8 - close the 1st telnet/ssh session, will free up pts/0 - using the other telnet/ssh session open one more screen session, it will get the pts/0 one At this point you have pts/0 to pts/7 all taken by screen sessions, now it's just impossible to login using telnet, the only way is ssh... Anyway I think an user that only really uses telnet should not be able to be in such a lock situation, because he should always have at least one free pts, the one he used to login initially, even if he disconnect/reconnect he should get on that same pts (unless there is some script or something creating screen sessions while he is not logged)... another issue may be if one telnet connection get's "stuck" by some network issue or something, guess may get him on similar lock situation eventually as that pts will get wrongly taken by the "ghost" connection...
  14. Sorry to bump this old topic, but I did found similar problem this morning and would like to leave a note here for others that eventually get same issue and find this topic, like I did... replying jonathanm question above, yes it seems screen uses sessions as well, in fact I had 0 telnet sessions running but some 10 screen sessions running and was unable to login one single telnet session, also getting ILLEGAL ROOT LOGIN on the log, however (fortunately) ssh worked fine.
Copyright © 2005-2017 Lime Technology, Inc. unRAIDĀ® is a registered trademark of Lime Technology, Inc.