Forum: Ruby on Rails UUIDTool and weird timestamp split error

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
34791e1d8c4def65f9b93294638a7e04?d=identicon&s=25 Joerg Diekmann (joergd)
on 2006-02-22 10:34
Hi,

I am using UUIDTools to generate my Guids. It works fine on my computer
(Windows Xp), but doesn't work on my host (TextDrive)

The error is:

Loading production environment.
>> UUID.timestamp_create.to_s
/sbin/ifconfig: Permission denied
NoMethodError: private method `split' called for nil:NilClass
        from ./script/../config/../config/../lib/uuidtools.rb:236:in
`timestamp_create'
        from ./script/../config/../config/../lib/uuidtools.rb:226:in
`synchronize'
        from ./script/../config/../config/../lib/uuidtools.rb:226:in
`timestamp_create'
        from (irb):8
>>


Any ideas what this could be? I am using ver 1.0 of UUIDtools.

Any help would be a life saver
Joerg
21f81822f22c2b08d96358ed69f6f6ed?d=identicon&s=25 Markus Strickler (Guest)
on 2006-02-22 11:57
(Received via mailing list)
Hi-

I'm completely new to rails - and ruby for that matter - but your
problem seems to be that UUIDTools try getting the MAC Address of
your network card by calling the program /sbin/ifconfig , which the user
rails runs under cannot execute.
Some soultions:
- Convince your provider to give oyur rails user execute permission on
/sbin/ifconfig
- install ifconfig for your rails user (you might also have to convince
the UUID code to use your local copy of ifconfig instad)
- convince the maintainer of the UUIDTools to implement another way to
retrieve the MAC address
- overwrite UUID.get_mac_address to return teh mac adress from a config
file instead of actually getting it from the network card

HTH,
-markus
34791e1d8c4def65f9b93294638a7e04?d=identicon&s=25 Joerg Diekmann (joergd)
on 2006-02-22 12:04
Cool. Just found another way ... you can use UUID.random_create to get a
Guid ... doesn't use the MAC address.


Markus Strickler wrote:
> Hi-
>
> I'm completely new to rails - and ruby for that matter - but your
> problem seems to be that UUIDTools try getting the MAC Address of
> your network card by calling the program /sbin/ifconfig , which the user
> rails runs under cannot execute.
> Some soultions:
> - Convince your provider to give oyur rails user execute permission on
> /sbin/ifconfig
> - install ifconfig for your rails user (you might also have to convince
> the UUID code to use your local copy of ifconfig instad)
> - convince the maintainer of the UUIDTools to implement another way to
> retrieve the MAC address
> - overwrite UUID.get_mac_address to return teh mac adress from a config
> file instead of actually getting it from the network card
>
> HTH,
> -markus
20381b12339f505894d6cff38d4696ca?d=identicon&s=25 Steve Sloan (Guest)
on 2006-02-23 00:31
(Received via mailing list)
Joerg Diekmann wrote:
> Cool. Just found another way ... you can use UUID.random_create to get a
> Guid ... doesn't use the MAC address.

Doesn't that defeat the purpose?  I thought the only way you could
guarantee
that an ID was truly unique was to include another unique ID, e.g. the
MAC
address, CPU ID, or some other hardware serial number.

A random ID, even combined with date/time, could still theoretically
collide
(e.g. if two machines happened to pick the same random value at the same
time).

-- Steve
2d0f17b478aa748b34afec2e5ec07b8d?d=identicon&s=25 Anthony DeRobertis (Guest)
on 2006-02-23 21:24
(Received via mailing list)
Steve Sloan wrote:

> A random ID, even combined with date/time, could still theoretically
> collide (e.g. if two machines happened to pick the same random value
> at the same time).

To have a ~50% chance of a collision, you must generate ~2^64 random
128-bit numbers. Considering the small subset of those 2^64 that will
actually be generated, the chance of duplicates happening randomly can
be ignored --- and its far less than the chance of either bugs in the
implementation or even duplicate MAC addresses accidentally being
assigned.
This topic is locked and can not be replied to.