ifconfig - missing on some distro's about fly HOT 14 CLOSED

So you want to fallback to ip addr when if config is missing and if ip addr is missing, you want to install one of them?

from fly.

Yes

from fly.

Ok, I will take care of it. And how do you want to determine which one of them to install? Let the user choose?

from fly.

No, i would like to keep just one user input (credentials). So the best way to choose would be find out which tool is on more distributions. I understand that both this tools are on most of distributions repositories, but we can consider not so standart distributions (or find out what is available for example on Mac). The other think is that we need to develop class for each distro (which will inherit from some interface) and do these install and data mining tasks specifically for that distro. I have some ideas how we can do it on our project, we can discuss it later on TS.

from fly.

I think we should think about a completely new technique about getting device UID, preferably using POSIX system utilities, as I think this is going a little bit out of control.

from fly.

Agree. We can discuss it on TS or later personally. It is too complex to discuss it via these comments.

from fly.

I still think that reading a fair ammount of bits from /dev/urandom would be the easier technique of getting unique IDs of UNIX clients.

@starek4 I know you aren't a big fan of it, but if reading 1024bits from properly seeded /dev/urandom is sufficient even for cryptographic applications, then we shouldn't even worry about getting two same strings [1].
The only problem is if the /dev/urandom isn't properly seeded, which may happen at kernel boot [2]. But since our client isn't launched until the user is at least logged in, I believe, there is plenty of time to properly seed /dev/urandom before launching our client.

I know, simply getting clients MAC address ensures total uniqueness, but do you really want to tackle all the hassle with the archives each for specific distribution? Don't get me wrong, I liked the whole idea with MAC addresses too, but we are simply done if ifconfig or ip programs are missing.
Another option is to simply state, that our client depends on this and this, then let the user to install these dependencies by himself (and maybe provide a quick tutorial in readme, how to install it). This way, we could also theoretically support all unix distributions, where the specified software is available.

from fly.

But with every start of our app user will see new device in his account (new device id). Only way is to store device id in user's PC and that I don't want to do.

I think we don't want to generate some random hash or string. We need to identify device with some device identifier.

from fly.

I totally forgot about persistence smh. Ok, never mind, if you don't want to store it, there is no point in considering it.

Then I suggest using ip command as primary source and fallback to ifconfig if necessary. It appears ifconfig is already deprecated and ip is much more universal. If either isn't installed, ten we should simply ask the user to install it. It's the same for dotnet, if user wants to use this client, he needs to install it anyways. Why don't we use the same approach for this case then?

Another possible way could be making device database more dynamic and when the client is shutting down, then the device gets deleted from database. The user will then launch client and besides login and password, he enters device ID. Then server side chceck for uniqueness would be enough. We can also don't need to work on client pings to server to see if the computer is online with this approach. And also provide manual device deletion on website too. Which reminds me - we don't even allow that now - created issue #18 for that.

from fly.

I agree with IP command. The second option has issues with loss of power or other scenarios. Let's try to keep it as simple as possible. It will be a huge benefit for incoming updates.

from fly.

How about the dependency installation? I suggest letting that to the user as I did in the most recent versions of scripts. He should know how to install it and with this approach, we can basically support any unix distribution. However, I would like to at least provide some kind of guide in readme for most common distributions , as for example at the TLP project.

from fly.

Yes, you can update readme.

from fly.

Just to keep things on track. This issue can be closed as I complete the installation instructions wiki.

from fly.

As we simplify the process of installation client, wiki pages are no longer needed.

from fly.