Open Menu

Synergex Blog


Taking .NET to the cleaners

By Richard Morris, Posted on November 22, 2010 at 2:23 pm

Ding dong, “Laundry service”! Now you could be mistaken for thinking that I’m staying in a rather nice hotel, being called upon by the maid for my dirty laundry. Not so, I’m afraid, I’ll be taking my dirty ‘smalls’ home with me. But for one of our customers, this is their calling card. The customer is White Knight, based near London and their business is laundry, run by Synergy.

It’s true. People and many of them are well known celebrities, have their laundry collected every Monday and returned within a few days, cleaned dried and perfectly ironed. Some ten thousand “items” pass through the machines at this site and this is a small site. Their other sites handle in excess of two hundred thousand articles every week.

To manage this workload across all sites is a suite of Synergy programs running on a Linux machine. Traditional character based systems handle all aspects of the process from collection, cleaning through to delivery of the right items to the correct customers.

But things don’t always go right. So when the customers call in and say “you’ve washed the spots off my favourite pair of shorts” it all needs to be recorded and processed. This calls for a CRM (Customer Relations Management) system. And here is where I enter the story. White Knight has invited me down to assist them to begin to write a fully functional CRM system in Synergy. They want a Microsoft Windows desktop application with all the bells and whistles with access to new and existing Synergy data and logic. Easy!

So today we hatched a plan. Graham from White Knight was fully prepared for my visit with a functional specification, data layouts and design utilising xfServerPlus. “But for a desktop application?” I asked. “Why are we not using WPF (Windows Presentation Foundation) and .NET?” Because I’m not strong with C#, I know enough to do my web site!” Graham replied. Well, given the imminent release of Synergy v9.5 and the integration of Synergy Language within Microsoft Visual Studio 2010 it would be a perfect candidate. We’ve created our Visual Studio projects and begun to define our WPF User Interface in XAML. Our existing Synergy routines are being imported into a new class library project and we are crafting Synergy classes to facilitate the communication between our application elements. For those of you at SPC 2010 you’ll recognise this as the Model-View-ViewModel pattern!

And how did we do? Well I’ll update my blog over the next few days of how well we do, writing our first Synergy for .Net application…..


Starting Services on Linux

By Steve Ives, Posted on July 24, 2010 at 3:14 pm

For a while now I’ve been wondering about what the correct way is to start boot time services such as the Synergy License Manager, xfServer and xfServerPlus on Linux systems. A few years ago I managed to “cobble something together” that seemed to work OK, but I had a suspicion that I only had part of the solution. For example, while I could make my services start at boot time, I’m not sure that they were getting stopped in a “graceful” way during system shutdown. I also wondered why my “services” didn’t show up in the graphical service management tools.

My cobbled together solution involved placing some appropriately coded scripts into the /etc/rc.d/init.d folder, then creating symbolic links to those files in the appropriate folders for the run levels that I wanted my services started in, for example /etc/rc.d/rc5.d.

This week, while working on a project on a Linux system, I decided to do some additional research and see if I couldn’t fill in the blanks and get things working properly.

My previous solution, as I mentioned, involved placing an appropriately coded script in the /etc/rc.d/init.d folder. Turns out that part of my previous solution was correct. For the purposes of demonstration, I’ll use the Synergy License Manager as an example; my script to start, stop, restart and determine the status of License Manager looked like this:

#

# synlm – Start and stop Synergy License Manager

#

. /home/synergy/931b/setsde

case "$1" in

   

start)

        echo -n "Starting Synergy License Manager"

       

synd

       

;;

   

stop)

       

echo -n "Stopping Synergy License Manager"

       

synd –q

       

;;

   

restart)

       

$0 stop

       

$0 start

       

;;

   

status)

       

if ps ax | grep -v grep | grep -v rsynd | grep synd > /dev/null

       

then

           

echo "License Manager is running (pid is `pidof synd`)"

       

else

           

echo "License Manager is NOT running"

        fi

       

;;

   

*)

       

echo $"Usage: synlm {start|stop|restart|status}"

       

exit 1

esac

exit 0

If you have ever done any work with UNIX shell scripts then this code should be pretty self explanatory. The script accepts a single parameter of start, stop, restart or status, and takes appropriate action. The script conforms to the requirements of the old UNIX System V init subsystem, and if placed in an appropriate location will be called by init as the system runlevel changes. As mentioned earlier, I had found that if I wanted the “service” to start, for example when the system went to runlevel5, I could create a symbolic link to the script in the /etc/rc.d/rc5.d folder, like this:

ln –s /etc/rc.d/init.d/synlm /etc/rc.d/rc5.d/S98synlm

Init seems to process files in a run level folder alphabetically, and the existing scripts in the folder all seemed to start with S followed by a two digit number. So I chose the S98 prefix to ensure that License Manager would be started late in the system boot sequence.

This approach seemed to work pretty well, but it was kind of a pain having to create all those symbolic links … after all, on most UNIX and LINUX systems, run levels 2, 3, 4 and 5 are all multi-user states, and probably required License Manager to be started.

Then, almost by accident, I stumbled across a command called chkconfig. Apparently this command is used to register services (or more accurately init scripts) to be executed at various run levels. PERFECT … I thought! I tried it out:

# chkconfig –-level 2345 synlm on

service synlm does not support chkconfig

Oh! … back to Google… Turns out I was something really critical in my script, and believe it or not, what I was missing was a bunch of comments! After doing a little more research I added these lines towards the top of the script:

# chkconfig: 2345 98 20

# description: Synergy/DE License Manager

# processname: synd

Low and behold, this was the missing piece of the puzzle! Comments … you gotta love UNIX! So now all I have to do to start License Manager at boot time, and stop it at system shutdown is use the chkconfig command to “register” the service.

And there’s more … With License Manager registered as a proper service, you can also use the service command to manipulate it. For example, to manually stop the service you can use the command:

# service synlm stop

And of course you can also use similar commands to start, restart, or find the status of the service. Basically, whatever operations are supported by the init script that you provide.

Oh, by the way, because License Manager is now running as a proper service it also shows up in the graphical management tools, and can be manipulated by those tools … very cool!

Of course License Manager is just one of several Synergy services that you could use this same technique with. There’s also xfServer, xfServerPlus and the SQL OpenNet server.


Linux ls Color Coding

By Steve Ives, Posted on July 20, 2010 at 4:32 pm

It’s always driven me CRAZY the way that RedHat, Fedora, and presumably other Linux systems apply color coding to various types of files and directories in the output of the ls command. It wouldn’t be so bad, but it seems like the default colors for various file types and protection modes are just totally unreadable … for example black on dark green doesn’t show up that well!.

Well, today I finally got around to figuring out how to fix it … my preference being to just turn the feature off. Turns out it was pretty easy to do, open a terminal, su to root, and edit /etc/DIR_COLORS. Towards the top of the file there is a command that was set to COLOR tty, and to disable the colorization all I had to do was change it to COLOR none. Problem solved!

Of course if you look further down in the file you’ll see that there are all kinds of settings for the color palettes to be used for various file types, file protection modes, etc. You could spend time “refining” the colors that are used … but personally I’m happier with the feature just GONE!


Don't miss a post!

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Recent Posts Tag Cloud Archives