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 <[email protected]>
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" <[email protected]> wrote:
>
> Michael, comments inline ...
>
> On Apr 24, 2018, at 6:10 PM, Michael Knill
> <[email protected]> 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" <[email protected]> wrote:
>>
>>
>> On Apr 24, 2018, at 2:16 AM, Michael Keuter <[email protected]> wrote:
>>
>>>
>>>> Am 24.04.2018 um 04:13 schrieb Michael Knill
>>>> <[email protected]>:
>>>>
>>>> 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
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>
>> Donations to support AstLinux are graciously accepted via PayPal to
>> [email protected].
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>
>> Donations to support AstLinux are graciously accepted via PayPal to
>> [email protected].
>
>
>
> ------------------------------------------------------------------------------
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to
> [email protected].
>
> ------------------------------------------------------------------------------
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to
> [email protected].
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to
[email protected].
