Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - mkbrown69

Pages: 1 [2] 3 4 ... 13
16
Users / Re: 64-bit install
« on: January 23, 2014, 03:19:04 am »
What's the host & hypervisor?  I do virtualization for a living, and short of architecture or endian issues, I have yet to see a 64-bit CPU that won't run 32-bit code (with the correct libraries of course); and that's talking Sparc, Power, and x86.

I run KVM on a Phenom II host with a 64-bit Kernel, 32-bit user land, and LMCE 32-bit running as a VM.  Before anyone thinks I'm crazy (hmmm, maybe? ;-). The host OS started life as a 32-bit Debian 3 install on an over-clocked Pentium 233 MHz, and has been through a number of in-place OS and hardware upgrades over the years, now currently Debian 7.1.  Multi-arch may let me finally go all 64-bit, or I may bite the bullet and re-install.  So much to do, so little time...

FYI, there is no current 64-bit LMCE builds...

HTH!

/Mike

17
Installation issues / Re: PXE boot MD
« on: January 14, 2014, 04:49:00 pm »
mkbrown,

is there a reason why you specify sh as the shell to run Diskless_CreateTBZ.sh instead of relying on the shebang line in the script itself?

Mostly to credit huh with the fix, and from working on RHEL and Debian where /bin/sh is normally linked to bash, but your point is valid; especially since Ubuntu is linking sh to dash now...  :-\

/usr/pluto/bin/Diskless_CreateTBZ.sh

is the proper way to execute the script B34N.  Thanks to posde for reminding me not to "assume".  I'll put it down to being sick right now...  ;)

HTH!

/Mike

18
Installation issues / Re: PXE boot MD
« on: January 14, 2014, 04:24:08 pm »
B34N,

Your issue is definitely due to the Diskless_BuildDefaultImage.sh script, which is called by Diskless_CreateTBZ.sh, not having been run.

As Huh indicated, you'll need to

sh /usr/pluto/bin/Diskless_CreateTBZ.sh

That will prepare the diskless images, and based on the other pastes, everything should just work at that point.

Thanks for the assist, huh!

/Mike

19
Users / Re: MD recommendations
« on: January 14, 2014, 03:37:50 am »
Dual channel RAM kits would work best, so look for 2 x 1G, 2 x 2G, etc kits, depending on your budget.  Those little NUC's will handle up to 16G of RAM! 

Some folks are actually running home VMware ESX clusters on them..  Just Google "NUC ESX Server" for a few interesting home lab builds...

/Mike


20
Installation issues / Re: PXE boot MD
« on: January 14, 2014, 03:27:48 am »
Hi B34N!

Something isn't quite right then...  SSH into your core, and run the following commands:

ls -la /tftpboot
ls -la /tftpboot/default
ls -la /tftpboot/pxelinux.cfg

cat /etc/dhcp/dhcpd.conf

cat /var/cache/bind/db.linuxmce.local

Paste the output of each, and we'll see what the current state is...

HTH!

/Mike

21
Installation issues / Re: PXE boot MD
« on: January 13, 2014, 02:46:44 pm »
I have an old Pentium 4 laptop, 512M of RAM, that I was net-booting off of a highly modified Diskless MD image which I'm using as a workstation in my workshop.  I was using the local disk as swap, to offset the limited RAM.  That was working fine off of 10.04, so I think you'll probably be fine net booting it.

I did an in-place upgrade to 12.04, which I'll be documenting over time.  I'm sick right now, so I don't feel like doing it at the moment... The diskless image I was using caused me issues in the core upgrade (no real support for Diskless Workstations, only MD's) so I had to delete it.  If you're doing a new install of 12.04, things will likely go just as described in the Wiki.  Once I got over all the upgrade hurdles, 12.04 on the core has been running pretty well for me (Disclaimer: I'm not running the Diskless MD's yet; production is still on another network using Minimyth). 

HTH!

/Mike

22
Developers / DNS inconsistencies, input sought.
« on: January 09, 2014, 04:10:59 am »
Hi Folks!

Being a sysadmin type, I'm now trying to work my way through various sysadmin type Trac issues.  I just patched a NIS issue (Thanks Phenigma for committing it!), and now I'm currently working on a DNS related one.  I'm doing the relevant patches against 10.04, and will diff against 12.04 as well (I'm currently running 10.04, and plan to do an in-place upgrade).

http://svn.linuxmce.org/trac/ticket/1769

Some of this is easy to fix, but some needs some input.  Three scripts actually backup and manage aspects of resolv.conf on the core (trunk/src):
BootScripts/Network_DNS.sh
BootScripts/Network_Parameters.sh
BootScripts/Network_Setup.sh

Would it not be better/easier to maintain if only one script managed that resolv.conf file?  I may be missing out on why it is the way it is, so I thought I'd put it out there for those more knowledgable about LMCE internals to comment...

Thanks for your time!

/Mike

23
Developers / Re: New Template ISY994i uploaded
« on: December 14, 2013, 04:13:22 pm »
Chris,

That was a lingering bug I had fixed in the last update I'd committed.   I'd refactored the code at one point, and forgot to rename that function call which is sitting in the event handler in a different code file.

This is where you need to go through the web admin, Advanced -> SQLCVS -> Update and then wait a while.  When it says success, you can then reload the router and check the logs.  Triggering some lights should generate the status update events, and you'll find your errors will disappear.

If they don't clear up, let me know...

HTH!

/Mike

24
Developers / Re: New Template ISY994i uploaded
« on: December 14, 2013, 01:17:39 am »
edited: Basically, GSD _SUCKS_ when you need to maintain more than one socket. Full stop.
-Thom

Thom,

I can understand your position.  Practically speaking, with the mysql dependency satisfied, the driver works pretty well.  The ruby/GSD driver does make for a good prototype platform, to finish the feature set. It's taken me the better part of a year to get it to this point, and that is with some ruby knowledge. I had to teach myself some more advanced ruby, XML parsing, plus the ISY SDK.  If I had to learn C++ simultaneously, it'd be another year before I got anything out...  ;)

I figure if I can get enough done and kitted out, someone more knowledgable than myself could port it to C++.

As a GSD, it's not perfect, but it does work well...

HTH!

/Mike

25
Developers / Re: New Template ISY994i uploaded
« on: December 14, 2013, 01:07:40 am »
Mike,

cat /var/log/pluto/55_Generic_Serial_Device.log
http://pastebin.com/itjtqGvP

Did you install ruby gems or some other package when your wrote the template.

Chris
Chris,

The pastebin isn't there anymore...

I didn't use ruby gems.  I have the following ruby-mysql packages on my core:
libmysql-ruby
libmysql-ruby1.8

apt-get install libmysql-ruby1.8 libmysql-ruby

would satisfy the mysql require.

HTH!

/Mike

26
Developers / Re: New Template ISY994i uploaded
« on: December 13, 2013, 06:56:11 pm »
Why does this driver require mysql?
Thom,

I'm querying the pluto database to look up the IP address of the device; I couldn't figure out a way to find it via device data.  If you can point me in the direction of that, I'll be able to remove the mysql requirement.  I thought the Ruby mysql drivers were installed as a LMCE dependency (which is why I was using them), but it could be that they are on my system due to some other products I'd installed.

The reader's digest version is that the conn_ method is used with the ISY's subscription channel (which is a one-way feed of events from the ISY to the "client", in this case the LMCE driver).  Commands have to be sent asynchronously as a separate REST call, and I have a function to do that.  The function hits the IP address, which I'm presently scraping from the DB, after first parsing the pluto.conf file to find the connection information.  The relevant DB scrape code is in the 355_Process_Initialize, and the REST command function is in 373_Private_Methods.  I can't establish the conn_ subscription until I've executed some REST calls to connect to the ISY and gather Child Device and other config data.  This was all done to make things work "automagically".

Chris,

Please stand by... based on Thom's assessment, your system is missing the ruby-mysql packages.  I suspect we'll have a way forward after Thom thwacks me upside the head...  :P

HTH!

/Mike

27
Developers / Re: New Template ISY994i uploaded
« on: December 13, 2013, 01:28:41 pm »
Hi Chris!

Man you're fast!  Been waiting for this for a while, eh?   ;)

My first thought is that you need to go through the web admin, Advanced -> SQLCVS -> Update and then wait a while.  When it says success, you can either reload the router, or reboot the core to have all the auto detection stuff happen via dhcp.  It should detect the ISY, then create the device as a child of the core.  You'll need to change your ISY credentials to match via the web admin, and reload the router.  After that, things should just work as per the wiki page.

If you're still having problems after that, can you pastebin or post the log files here as attachments?  I'll need the <dev#>_Generic _Serial_Device.log and <dev#>_ISY-994i-GSD.log.  Both are located in /var/log/pluto, and can be found using

ls <dev#>_*

Mine are 189_Generic_Serial_Device.log and 189_ISY-994i-GSD.log (as an example).

I'll look at them tonight if you're still having problems.  I think you just got bit by the misaligned code (it got attached to a different device in the SQLCVS number shuffles...

/Mike

28
Developers / Re: New Template ISY994i uploaded
« on: December 13, 2013, 04:28:20 am »
Hi Thom!

I'm guessing that no news is good news, and that I'm on the right track.  I've done another anonymous SQLCVS commit. Would you be able to review it and let me know if it looks OK?  Dec 12th @ 22:20 EST, against Trac #1999.

Thanks!

/Mike

29
Developers / Re: New Template ISY994i uploaded
« on: December 09, 2013, 05:10:38 am »
Hi Thom!

I modified the template first to re-associate it with Universal Devices (#1163).  That's what I committed early this morning.  Later, I noticed the code wasn't associated, so I started looking into the tables. 

I modified table 'InfraredGroup_Command.FK_InfraredGroup' for all affected rows to match the relevant row from 'infraredGroup.PK_InfraredGroup'.  The old value was 6143 (which matched the Google ChromeCast values), and I changed it to 6102 for the ISY.  I noted the behavior for LMCE creating new command groups, deleted the new (blank) rows, and changed the FK_InfraredGroup value for the pre-existing ones. 

Let me know how you want me to proceed...

Thanks again!

/Mike

30
Developers / Re: New Template ISY994i uploaded
« on: December 09, 2013, 03:36:12 am »
Thom,

I've noticed that the code got tied to the Google manufacturer ID, which meant it wasn't working with the driver the way it should.  I've figured out how to fix it locally by modifying the database tables directly.  I'm not sure if doing a SQLCVS commit now will make things better or worse, so I'll wait on your advice.

Thanks for your assistance with this!  It's greatly appreciated!

/Mike

Pages: 1 [2] 3 4 ... 13