On Sunday 03 Apr 2011, gurteshwar singh wrote: > 1) Regarding support and access: Setting up telephony systems is not > such an easy job and messing them up seems to be even easier. So my > question is how much of access do you give the organisation's > in-house support team on your servers. Do you for example take the > risk of asterisk config files getting messed by somebody at your > client's location? Or do you only expose only the dynamic parts of > the system (adding users, retrieving call recordings etc). I imagine > it would be mandatory to give them root access. Is that correct? If > yes, then is it the case of implementing as many safeguards as you > can?
Support falls into two categories: 1. Operational support -- diagnosing and fixing problems, adding resources, monitoring, etc. 2. Provisioning -- adding desktops, configuring for specific users, adding Asterisk accounts, etc. For the first we've tried to create base documentation which the client's tech team can use to monitor, diagnose and fix common problems. Out of the whole tech team, there are two people who have the authorisation to login as root onto the Asterisk servers and run diagnostics and fixes. One has years of Unix experience, the other is a Windows wiz-kid who's learning Linux and seems, so far, to be enjoying it. He paid me the ultimate compliment the other day, saying he was -- and I quote -- "the Raj Mathur of Windows". Provisioning is handled completely through scripts. Asterisk provisioning is handled by keeping base configurations in immutable files, which #include the files that contain the changing information. These dynamic files (user extensions, user-level call routing, inward routing, etc.) are again generated through scripts and copied by one of the two people mentioned above to the appropriate place in the Asterisk servers on a regular basis. Provisioning of desktops for a specific user is completely scripted: login as guest, ssh to a specific account on a defined server which will prompt you for an employee ID, enter the ID, sit back for 2 minutes and the machine you were on is provisioned for that employee. There's still lots of scope for improvement here, but we're in no hurry to implement systems piece-meal. The organisation has an IT strategy, and the voice system processes too will get streamlined as dependent portions of the strategy fall into place. For instance, once HR processes are in place, Asterisk user provisioning will automatically become a part of those. Of course, we would have shifted to Asterisk Realtime (dynamic configurations from a database rather than static configurations from file) too by then. > 2) Licensing: How do you go about explaining them the license. Do you > just list major parts like asterisk and debian and tell them we used > this and its licensed under so and so foss license? Is there detailed > written license documentation to be provided or just providing links > to licenses sufficient? Actually that is one thing we haven't had any issues with, since the CTO understands FOSS licensing. The only time we had to explain things was when he saw me writing a script and putting the GPL clause at the top. However I explained to him that licensing and releasing were two different things, and just because the script was GPL didn't mean that he had to give it to anyone for the asking. I think the point got through. Regards, -- Raj -- Raj Mathur r...@kandalaya.org http://kandalaya.org/ GPG: 78D4 FC67 367F 40E2 0DD5 0FEF C968 D0EF CC68 D17F PsyTrance & Chill: http://schizoid.in/ || It is the mind that moves _______________________________________________ Ilugd mailing list Ilugd@lists.linux-delhi.org http://frodo.hserus.net/mailman/listinfo/ilugd
