SSH Tunnels

SSH allows us to play some tricks with the local ports and enable ssh tunnels for port forwarding. This allows for some nifty tricks in restricted corporate environments, to access the real world wide web and nothing else ofcourse.

There is small nuance while configuring ssh tunnels. The tunnels are bound to the localhost:portnum. Now trying to access localhost_ip:portnum doesnt resolve to the same port (remember a port is always referred to as a combination of ip+portnum).

127.0.0.1:605 = localhost:605 != localhost_ip:605

This is because [ man ssh(1) ] while doing port forwarding

     -L port:host:hostport
         Specifies that the given port on the local (client) host
         is  to  be  forwarded  to the given host and port on the
         remote side. This works by allocating a socket to listen
         to  the port on the local side. Then, whenever a connec-
         tion is made to this port, the connection  is  forwarded
         over the secure channel and a connection is made to host
         port hostport from the remote machine.  Port forwardings
         can  also  be  specified in the configuration file...

Now what if you want to use the localhost_ip:port instead then [ man ssh(1) ]

     -g
         Allows remote hosts to connect to local forwarded ports.

Chillax... Have fun

Some OpenSolaris Annoyances

1) There is no -R option in most of the basic shell utilities. Yeah I know I can always download the gnu equivalent too.
2) 64 bit libraries are placed in /lib/am64. This is crappy especially when you are compiling from source and most configures would expect the libpath to end at /lib
3) Too man locations for libs and binaries. We have /usr/[bin,lib] /usr/local/[bin,lib] /opt/csw/[bin,lib] /usr/sfw/[bin,lib]. Worse most of them are not included in the path by default, we need to set them up.
4) Compilations on 64 bit systems dont generate 64bit binaries by default
5) Even the Sun Studio compilers use dumb options for default... remember stlport. Comeon guys.

Maybe we are sacrificing a lot for ensuring backward compatibility. At the end of the day we need to assure that we have a easily usable system.

Note: Binary compatility rocks but maintaining everything just doesnt seem to make sense. After all how many people use Solaris 7 binaries on Solaris 10.

OpenSolaris Custom Search Engine

Sitting idle I just went ahead and created a custom search engine for OpenSolaris on the Google Co-op website

OpenSolaris Custom Search

I've just added some 17 sites that I find useful for my solaris problems. Will add more as I go along and if I get some inputs from anyone.

Cheers

boosting your c++ apps

Boost seems to be the answer to most of my prayers when it comes to getting some extended C++ help. But there is one thing that is totally unknown to me and that is how to understand "bjam". Now I was trying to compile boost on a 64bit system and by default the compilation results in 32bit shared objects. Tried high and low to search for someone who managed to get it compiled in 64bit but well I couldnt, maybe because boost shows up as something else on google :)

Anyways here is the simple way to do it.

(get into the tools/build/jam_src dir)
./build.sh
(go back to the boost home dir)
./tools/build/jam_src/bin.solarisx86/bjam -sTOOLS="gcc" -sBUILD=" < cxxflags > -m64 < linkflags > -m64"

Now if you want to go ahead and use the sun studio compilers you need to do this

(get into the tools/build/jam_src dir)
./build.sh sunpro
(go back to the boost home dir)
./tools/build/jam_src/bin.solaris/bjam -sBUILD=" < threading > multi  < runtime-link > dynamic 
 < cxxflags > -xarch=native64" -sTOOLS="sunpro"
-sSUNPRO_CXX="/opt/SUNWspro/bin/CC -library=stlport4 -xarch=native64" 
 -sSUNPRO_ROOT_DIRECTORY="/opt/SUNWspro/"

Now you should have a working 64bit copy of all the boost libraries.

Opensolaris installed. What next?

Done with the solaris installation and want to play around now. Here are some of the sites that I use to learn more about my favourite OS.

http://developers.sun.com/sunstudio/articles/amd64_migration.html - tips on migrating code from x86 to x64 and some tips on moving from gcc to sunstudio

http://blogs.sun.com/rie/date/20061219 - on why ld cant exactly locate _init and _fini

http://blogs.sun.com/sga/ - tips and tricks for getting boost c++ libs going

http://forum.java.sun.com/thread.jspa?threadID=5075258&messageID=9274275 - getting started with dtrace on available binaries

http://prefetch.net/articles/dtracecookbook.html - collection mechanisms/tools and what do they exactly display

http://blogs.sun.com/brendan/ - brendan gregg's cool dtrace toolbox and all his other gyan on zones, zfs and more

http://solaris.reys.net/english/categories/3-DTrace/P4.html - cool dtrace guy with some nift tricks other than those from Brendan Gregg

Yippe Yaah!!

Ian Murdoch, the founder of the extremely popular Debian system, has just picked up an offer from Sun Microsystems. He will be joining them towards aligning the strategy of the company towards fighting the competitive edge that linux has ( and yes it does have an edge on things like drivers and usability features ). Maybe fighting is not the right word but aligning is.

Ian has been supportive of the Debian/Ubuntu packaged OpenSolaris distro -Nexenta and has giving his reasoning on his blog. He essentially beleives that open source under any license serves the end goal of being better for the community eventually. Ofcourse the blinded and half baked comments of the so called Linux gurus on his site show how much people are blinded by their incomplete facts based faith.

There's no doubt that he is good, the bonus is that he has a soft spot for Sun too. And the fact that Sun is actually hiring such a guy shows that Sun is really fighting hard to make sure it understands all the aspects of the open source game and Ian is just the right kinda person to help.

some nagging c++ questions

C++ always has some tricks in there that you just don't know about. Here are a couple of features/issues that I've run into. Am sure this list is pretty huge but lets start with three of them and my explanations for the same.


a) using "using namespace" in your header files

I was once asked why I go ahead and take the trouble to do a std::string in my header files instead of just including the "using namespace std" statement and moving along. There are a variety of reasons why the former is considered to be a good practice. Some of those are written in Herb Sutter's More Exceptional C++ book and many newgroups have their own threads on this issue (see namespace pollution).

For me the main reason was because of the namespace pollution caused when I have some headers with the "using" statement and some without and then being included in a particular sequence in a third header file. This as I remember caused some collisions. Other than that it also causes problems when you go ahead and include all these headers in your own namespace, thereby also including the "using" statement into your namespace, more problems.


b) the need to have template class functions as inline

Template classes are essentially compiled on demand. Once the compiler seems a template instantiation it goes back to where the declaration was seen and generates the type specific code of the template class immediately. Now while doing so it needs to generate the entire object code for the class. If we go ahead and sperate our template class into a .h declaration and .cpp definitions files then the compiler is left with incomplete information about what needs to be generated for this class. This is the reason why most compilers will cribb here. But this is a compiler issue rather than the C++ standard itself.


c) template functions in tempate classes

yes it is possible to do that. you just need to be a lil carefull thats all.

template < class x >
class tclass
{
 public:
        x var;
  tempate < typename y >
  void func(y);
};

template < class x >
template < typename y >
void func( y fvar )
{ ... }