Hi Michael.au, :-)

> It is proprietary as far as I can gather but it does seem to work and appears 
> to be fairly autonomous. Is there anything I should be watching out for?

I did a "ldd" of uniloader_amd64
--
        linux-vdso.so.1 (0x00007ffe4bd71000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00007f13a07ad000)
        libc.so.6 => /lib/libc.so.6 (0x00007f13a0435000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f13a09c9000)
--
and a 'strace' as it started and did not see anything alarming.

Though I'd be interested how they did their crypto, it must be statically 
linked within their binary.

The Loway folks have a github presence:
https://github.com/Loway

They really should make their source public, even if it has a "sole purpose of 
using" license as Tarsnap does
https://github.com/Tarsnap/tarsnap/blob/master/COPYING


> I will let you know how I go.

Please do.

Lonnie


On Apr 24, 2018, at 9:03 PM, Michael Knill <michael.kn...@ipcsolutions.com.au> 
wrote:

> Hi thanks Lonnie
> 
> Whoops there is a --pid option so I should use that in the init script then. 
> "killall uniloader" did work too.
> I will also put it in rc.local thanks. So would it be best to kill the 
> process in rc.local.stop? Is this best practices?
> It is proprietary as far as I can gather but it does seem to work and appears 
> to be fairly autonomous. Is there anything I should be watching out for?
> I guess the proof is when I install it in production. I will let you know how 
> I go.
> 
> Thanks again.
> 
> Regards
> Michael Knill
> 
> On 25/4/18, 9:45 am, "Lonnie Abelbeck" <li...@lonnie.abelbeck.com> wrote:
> 
>    Michael, comments inline ...
> 
>    On Apr 24, 2018, at 6:10 PM, Michael Knill 
> <michael.kn...@ipcsolutions.com.au> wrote:
> 
>> Hi thanks Lonnie and Michael for the info.
>> 
>> As I don't know of any stop requirements for uniloader I was thinking of 
>> doing the following (eventually):
> 
>    It is always good to implement stop, "killall uniloader" might do it.
> 
>> - Have a queuemetrics.conf file in /mnt/kd which contains all the parameters 
>> required for the uniloader including whether it is enabled or not
>> - Build a script which is included permanently in rc.elocal which reads this 
>> config file and runs the application if enabled with the read parameters
> 
>    rc.elocal runs quite early in the boot process, you might want to use 
> /mnt/kd/rc.local and /mnt/kd/rc.local.stop which occurs near the end of the 
> boot process.
> 
>> - I will also try to monitor the application with monit which restarts it 
>> using the above script if it crashes
> 
>    Again, you want to implement 'stop'
> 
>> 
>> How does this sound? Am I missing something?
>> Should I place the uniloader bin file in /usr/sbin or would I put it in 
>> /mnt/kd/bin or somewhere else?
> 
>    Definitely don't use /usr/sbin space, using /mnt/kd/bin would be fine and 
> all under your control.
> 
>> PS I will also be running up the unitracker which is included in the 
>> uniloader which monitors outgoing calls as well!
> 
>    Question, are these proprietary binary blobs ?  Or can they be compiled ?
> 
> 
>> 
>> Thanks so much.
> 
>    Lonnie
> 
> 
> 
>> 
>> Regards
>> Michael Knill
>> 
>> On 24/4/18, 10:39 pm, "Lonnie Abelbeck" <li...@lonnie.abelbeck.com> wrote:
>> 
>> 
>>   On Apr 24, 2018, at 2:16 AM, Michael Keuter <li...@mksolutions.info> wrote:
>> 
>>> 
>>>> Am 24.04.2018 um 04:13 schrieb Michael Knill 
>>>> <michael.kn...@ipcsolutions.com.au>:
>>>> 
>>>> Hi All
>>>> 
>>>> I am now currently testing QueueMetrics V17 with the uniloader application 
>>>> and it does appear to be working.
>>>> More testing is required but I was just wondering where I should be 
>>>> putting this file, how to start it on bootup and how to restart it if it 
>>>> crashes.
>>>> 
>>>> The command to load is recommended as (and I used):
>>>> nohup nice ./uniloader -s /var/log/asterisk/queue_log upload --uri 
>>>> "mysql:tcp([qmserver ip address]:3306)/queuemetrics?allowOldPasswords=1" 
>>>> --login [loginname] --pass [password]e --token P001  >> 
>>>> /var/log/uniloader.log &
>>>> 
>>>> Thanks. I will let you know how I go.
>>> 
>>> I would put the above command into its own script (e.g. in /mnt/kd/bin/) 
>>> and then start it from "/mnt/kd/rc.local", which runs at the end of the 
>>> boot process.
>>> Maybe you can track it then from Monit.
>>> 
>>> If you need to do something on reboot/shutdown, you could use 
>>> "/mnt/kd/rc.local.stop" as well.
>> 
>>   Totally agree with Michael.
>> 
>>   Model your /mnt/kd/bin/ script after a simple /etc/init.d/ script like 
>> /etc/init.d/acpid and call it as Michael suggests from /mnt/kd/rc.local and 
>> /mnt/kd/rc.local.stop.
>> 
>>   Lonnie
>> 
>> 
>>   
>> ------------------------------------------------------------------------------
>>   Check out the vibrant tech community on one of the world's most
>>   engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>   _______________________________________________
>>   Astlinux-users mailing list
>>   Astlinux-users@lists.sourceforge.net
>>   https://lists.sourceforge.net/lists/listinfo/astlinux-users
>> 
>>   Donations to support AstLinux are graciously accepted via PayPal to 
>> pay...@krisk.org.
>> 
>> 
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Astlinux-users mailing list
>> Astlinux-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>> 
>> Donations to support AstLinux are graciously accepted via PayPal to 
>> pay...@krisk.org.
> 
> 
>    
> ------------------------------------------------------------------------------
>    Check out the vibrant tech community on one of the world's most
>    engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>    _______________________________________________
>    Astlinux-users mailing list
>    Astlinux-users@lists.sourceforge.net
>    https://lists.sourceforge.net/lists/listinfo/astlinux-users
> 
>    Donations to support AstLinux are graciously accepted via PayPal to 
> pay...@krisk.org.
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Astlinux-users mailing list
> Astlinux-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
> 
> Donations to support AstLinux are graciously accepted via PayPal to 
> pay...@krisk.org.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Astlinux-users mailing list
Astlinux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/astlinux-users

Donations to support AstLinux are graciously accepted via PayPal to 
pay...@krisk.org.

Reply via email to