License only Flash drive

[NAS]

Old topic but since unRAID community is accelerating its worth touching again.

 

Whats people opinions on having a two USB key setup. One key with unRAID as is and another that needs to be in place for it work i.e. the license key

 

The difference is that this license key wouldn't age the same as the constantly in use with lots of reads and writes main key.

 

Theres some technical hurdles obviously but on the face of it the idea has some legs

[jimwhite]

+1

 

[Biggy2872]

Old topic but since unRAID community is accelerating its worth touching again.

 

Whats people opinions on having a two USB key setup. One key with unRAID as is and another that needs to be in place for it work i.e. the license key

 

The difference is that this license key wouldn't age the same as the constantly in use with lots of reads and writes main key.

 

Theres some technical hurdles obviously but on the face of it the idea has some legs

 

I just want to make sure I have the right idea... You basically want to make one USB key a "dongle" that contains ONLY they KEY and is not available for free space?

 

I like the idea but I wanted to throw another idea out there...

 

What about making a custom unraid boot that mounts one key to /boot/config (tied key to license) and then mount the other key to /boot?  would this work?  I'm not sure how the key validation works and whether this would effect it negatively.

 

Cheers,

Matt

[NAS]

The only thing i was getting at is that the flash drive that is most likely to break (due to it being the one used all the time) is not the same key as the license key.

 

How we get there is completely open to debate

[SSD]

I think you have to ask some of the basic questions ...

 

1.  Are we having lots of USB failures?

2.  Are the failures we do have caused by overuse of the stick?

3.  Would having 2 USB sticks cause fewer end user problems?

4.  When a USB failure occurs, is Tom slow to respond causing users days of lost use of their arrays?

5.  Would this make it easier for new users to install unRAID?  (I can see a whole new class of problems where users don't know which USB should be the boot usb?)

 

1 USB stick = necessary evil so Tom gets paid

2 USB sticks better and 1?

 

I think not.

[NAS]

Inline:

 

1.  Are we having lots of USB failures?

 

Who knows. Whats lots?

 

2.  Are the failures we do have caused by overuse of the stick?

 

Ask that again after 5 more years of using the exact same stick

 

3.  Would having 2 USB sticks cause fewer end user problems?

 

End user problems not the same as failed impossible to use unRAID install

 

4.  When a USB failure occurs, is Tom slow to respond causing users days of lost use of their arrays?

 

An hour at the wrong time is as bad as a day in a commercial product. hes just a guy he cant respond 24*365

 

5.  Would this make it easier for new users to install unRAID?  (I can see a whole new class of problems where users don't know which USB should be the boot usb?)

 

Who knows it doesnt exist yet

[WeeboTech]

If we had union file system ability then this would be possible without significant issue.

You could union /boot with a directory on another flash or a directory on a hard drive (or raid drive).

If we had union ability you may not even need the space on /boot but it could be any directory anywhere.

 

[Joe L.]

I think you have to ask some of the basic questions ...

 

1.  Are we having lots of USB failures?

I think I remember about 8 or 10 mentioned in this forum over three years.

2.  Are the failures we do have caused by overuse of the stick?

One was lost during assembly  (this was NOT overuse, in fact it was never used)

Two were snapped in half as the server was moved or repositioned, (definitely, overused)

One was eaten by the family dog,   (yup, that is overuse)

Several others failed electrically and could not be read reliably.    (might be overuse, might be cheap chips inside)

3.  Would having 2 USB sticks cause fewer end user problems?

Possibly... in fact, Tom may think so too, that might be why he sells the second key at a discount.

4.  When a USB failure occurs, is Tom slow to respond causing users days of lost use of their arrays?

unknown... don't remember anybody complaining really badly about this occurring.

5.  Would this make it easier for new users to install unRAID?  (I can see a whole new class of problems where users don't know which USB should be the boot usb?)

I think it would complicate things.

1 USB stick = necessary evil so Tom gets paid

2 USB sticks better and 1?

 

I think not.

Tom already sells two keys, at a slight premium over one.   Having a second key formatted and loaded, even if not licensed will allow you to get to any 2 of your data disks until you can get a new license key file.   To me, that is the smartest thing you can do.

 

Joe L.

[Biggy2872]

My desires for a second key are in terms of additional space for user mods... if today we say that 1 gig should be enough but find out a year or two for now, that the minimum size requirement now exceeds this (extreme example, but others use 256-512MB drives) for our add-ons... I would have a perfectly good flash that does not provide me with enough room and therefore I need to buy a new license to use the operating system/features I already paid for...

 

By allowing a second drive to be mounted to provide additional room for installs would be helpful... I would say that we should keep the unraid flash as is but add the ability to mount a second drive with user addons on boot (basically migrating /boot/custom to another drive)  this would reduce the wear and tear on the first drive (only used for boot and regular use), the second drive would get the use from the user add-ons (unmenu, preclear.. etc) and plenty of room to save logs, etc.

 

Cheers,

Matt

[NAS]

In theory moving to a license only key poterially opens up option for boot from any type of device as well.

 

What would be even better is if the key could be removed once the server is booted. I doubt this would ever happen as it would allow for licesne stealing but it would be cool if the license key (which eventually could be the encryption key) could be put in a safe place.

 

This all could be a flight of fancy but what you dont debate never gets done.

[limetech]

If we had union file system ability then this would be possible without significant issue.

You could union /boot with a directory on another flash or a directory on a hard drive (or raid drive).

If we had union ability you may not even need the space on /boot but it could be any directory anywhere.

 

Looking to do exactly this in 5.0 version.

[NAS]

tease

 

Limetech have to say its excellent your getting in with comments on these posts really makes a difference. kudos

[WeeboTech]

My desires for a second key are in terms of additional space for user mods..

 

By allowing a second drive to be mounted to provide additional room for installs would be helpful... I would say that we should keep the unraid flash as is but add the ability to mount a second drive with user addons on boot (basically migrating /boot/custom to another drive)  this would reduce the wear and tear on the first drive (only used for boot and regular use), the second drive would get the use from the user add-ons (unmenu, preclear.. etc) and plenty of room to save logs, etc.

 

This can be done today. In fact it does not have to be a flash drive.

It can be a directory on your unRAID array, a directory on another flash or a file image on some location.

I.E.

As long as people adhere to the /boot/custom tree then you can mount a directory with

 

mouint -o bind /mnt/disk1/somedirectory /boot/custom

or mount another flash drive with

mount -L UNRAIDDSUPP /boot/custom

or a file image via loopback(if it is compiled in the kernel).

 

In theory moving to a license only key potentially opens up option for boot from any type of device as well.

Agreed. But this can be done today.

You can boot from a hard drive. I've done it. It still refers back to the flash later on after mount. Comes up much faster.

In fact using grub4dos, I'm able to boot from a floppy, read the hard drive image of the files and after loading the rootfs the system mounts the USB key where it's supposed to be.

 

I would like the idea of some way to identify the GUID/Key location in a path. Then have emhttp verify if the GUID is plugged into the system anywhere rather then on a specific path. 

In this case you could have the Key on the system and not require mounting the key and mount whatever you want on /boot.

However this does complicate things.

 

In the end unioning would provide the easiest solution as /boot would exist on the flash and updates could be applied to some other directory and then visible on /boot.

 

 

 

 

 

[Joe L.]

or mount another flash drive with

mount -L UNRAIDDSUPP /boot/custom

or a file image via loopback(if it is compiled in the kernel).

The loop devices are there... I've used them to mount file images.

 

Joe L.

[SSD]

Are the disks available prior to starting the array?  I've noticed that after boot (and if the array doesn't start) only the "flash" share is available.  I have a custom share setup to the cache disk (which I use partially as an unprotected data disk).  I wonder if there is a way to get it to mount and share immediately - like "flash" does.  Would that allow you to create symlinks from flash to the cache disk for some of the bootup tasks (e.g., packages)?

[WeeboTech]

Are the disks available prior to starting the array?  I've noticed that after boot (and if the array doesn't start) only the "flash" share is available.  I have a custom share setup to the cache disk (which I use partially as an unprotected data disk).  I wonder if there is a way to get it to mount and share immediately - like "flash" does.  Would that allow you to create symlinks from flash to the cache disk for some of the bootup tasks (e.g., packages)?

 

The disks are not there until the array is started.

This is why it was requested to have an event execute after the array was started.

 

What I have done was a pausing loop that waited for the /dev/md devices to come online.

 

Now if you partitioned the cache drive manually setting partition 1 for unraid's cache usage and another partition for your own usage, you could mount  the second partition wherever  and whenever you felt appropriate.

 

 

 

[Biggy2872]

Are the disks available prior to starting the array?  I've noticed that after boot (and if the array doesn't start) only the "flash" share is available.  I have a custom share setup to the cache disk (which I use partially as an unprotected data disk).  I wonder if there is a way to get it to mount and share immediately - like "flash" does.  Would that allow you to create symlinks from flash to the cache disk for some of the bootup tasks (e.g., packages)?

 

This kind of the idea I was trying to get across in my previous post... but thinking about it... if we mount in the go file (pausing for a some time to allow the mount to do it's job) BEFORE the line to run the start-up script in the TPA, then the packages and boot-up addons should still work if located on a second flash drive... no?

 

Cheers,

Matt

[dandirk]

hmmm just a noob with an idea...

 

Maybe have an option* to allow unraid to call home?  This could remove the whole idea of needing a key with USB flash guid?

 

Obviously you could support the old key method for users that don't want their unraid server internet access...

 

Maybe another USB key that will authenticate/activate or even call home to setup a new usb key (and disable the old)?  Then you "license" drive could be stored and used minimally for less risk of failure.