10:24:35 up 1000 days, 2:43, 1 user, load average: 0.11, 0.13, 0.09
I admit it, my first reaction is, "How cool is THAT?". But then this little voice in my head says, "Yeah, but that means it's been an awfully long time without a kernel patch."
Friday, February 25, 2011
Cool or Embarrassing?
I admit it, my first reaction is, "How cool is THAT?". But then this little voice in my head says, "Yeah, but that means it's been an awfully long time without a kernel patch."
Thursday, June 03, 2010
ndd-nettune.xml not quite right (from DSEE7 docs)
If you try to follow the current revision of docs for Sun Directory Server Enterprise Edition 7 (or for that matter, the DSEE 6.x as well) you will find references to installing a SMF manifest called ndd-nettune.xml. In the DSEE7 process, it comes in the Sun Directory Server Enterprise Edition 7.0 Deployment Planning Guide.
When you install the provided manifest, and run svccfg validate on it, you are slapped across the face with a useless error indicating that the file can not be parsed. Hmm, thanks. I'm the first to admit that my XML skills are basic; I'm not a full time software developer, I just play one on TV.
After some digging around I decided to model the stock coreadm manifest that is extremely similar. It can be found at /var/svc/manifest/system/coreadm.xml. With some minor editing, it was pretty easy to get it working. I believe the issue is in the exec_method tags not being properly terminated. It's a bit of a PITA to post XML into this blog, but if you take a look I think you'll see what I mean. The newly edited manifest imported without complaint, and I'm back on track with the installation.
I also stumbled onto a neat tool which was new to me. Not being satisfied with the lame error message svccfg spat at me, I dug up a utility called "xmllint" which has much more interesting diagnostics. I'm not sure how to interpret what it gave me, but with a little time I'm sure I could have leanred and benefitted from it. Something to file away in the Jedi library for a rainy day.
When you install the provided manifest, and run svccfg validate on it, you are slapped across the face with a useless error indicating that the file can not be parsed. Hmm, thanks. I'm the first to admit that my XML skills are basic; I'm not a full time software developer, I just play one on TV.
After some digging around I decided to model the stock coreadm manifest that is extremely similar. It can be found at /var/svc/manifest/system/coreadm.xml. With some minor editing, it was pretty easy to get it working. I believe the issue is in the exec_method tags not being properly terminated. It's a bit of a PITA to post XML into this blog, but if you take a look I think you'll see what I mean. The newly edited manifest imported without complaint, and I'm back on track with the installation.
I also stumbled onto a neat tool which was new to me. Not being satisfied with the lame error message svccfg spat at me, I dug up a utility called "xmllint" which has much more interesting diagnostics. I'm not sure how to interpret what it gave me, but with a little time I'm sure I could have leanred and benefitted from it. Something to file away in the Jedi library for a rainy day.
Wednesday, June 02, 2010
Got Webstack?
Did anyone else notice that the Sun Webstack appears to have quietly disappeared from download-ability? 1.5 was released in the summer of 2009, and now it appears to be quite the maze of links leading nowhere.
I can find wikis and articles, but the links all lead to a general page and searches on oracle.com lead nowhere. Sure would be nice if they'd at least posted a "so long and thanks for all the fish" notice.
Webstack, webstack, where art thou, webstack?
I can find wikis and articles, but the links all lead to a general page and searches on oracle.com lead nowhere. Sure would be nice if they'd at least posted a "so long and thanks for all the fish" notice.
Webstack, webstack, where art thou, webstack?
Tuesday, March 30, 2010
To syslog, or not to syslog? That is the question.
At $WORK we have a simple application which acts as a wrapper around common account management tools. Its purpose is to ensure that all account move/add/change implementations are logged with who did the work and what ticket authorized it, etc. The method for this logging is currently syslog. I'm not sure sure that I would have chosen that design, and that is the topic of this post.
In general I'm made to suffer by observing the slow decay of UNIX practitioners. That's not to say that use of UNIX is in decline, but rather that people who understand UNIX are becoming fewer and farther between. Note that in this case, I lump Linux and UNIX together. So many people are hopelessly tainted by their knowledge of Windows that it creates a prism through which the light of every operating system is split between reality and perception.
UNIX is more than an operating system. It is a development platform. It contains the tools you need to handle many application components including logging, messaging, file parsing, etc. And yet, we find people frequently turning to proprietary (or sometimes open) tool kits to solve problems the OS is well equipped to handle. It frustrates me.
Given that I'm a strong proponent of using the Operating System's features to solve problems, why wouldn't I like the idea of a local script using syslog to handle its logging? The biggest reason is that today's Solaris syslog facility remains tightly constricted in its use of facilities and levels. Yes, I'm well aware that syslog-ng can open those doors. I'm all for it! However, someone at Sun (Oracle) doesn't seem to be all for it yet, and I'm not a big fan of re-plumbing core OS features. So, until Sun sees the light and modernizes the syslog facility I believe in sticking with the standard.
One approach that may be acceptable is combining all Operational logging into a single facility. The trouble with that approach is that we have some logs which fall under tougher security policies than others, so you end up needing destination files with different attributes. So, what's the answer to the engineer's dilemma?
If an application needs to send its output for Enterprise-wide real-time processing for something like a log watcher, then it may be appropriate to use syslog in order to leverage its ability to forward log streams to syslog servers. But if you are writing a simple application which diligently generates log files for audit or troubleshooting purposes, you may be better off in the long run by writing a simple log function that dumps to a configurable destination file. Of course, your log files will be stored under /var/opt/something and will integrate with logadm(1M), right? Of course. After all, you are a Jedi...
In general I'm made to suffer by observing the slow decay of UNIX practitioners. That's not to say that use of UNIX is in decline, but rather that people who understand UNIX are becoming fewer and farther between. Note that in this case, I lump Linux and UNIX together. So many people are hopelessly tainted by their knowledge of Windows that it creates a prism through which the light of every operating system is split between reality and perception.
UNIX is more than an operating system. It is a development platform. It contains the tools you need to handle many application components including logging, messaging, file parsing, etc. And yet, we find people frequently turning to proprietary (or sometimes open) tool kits to solve problems the OS is well equipped to handle. It frustrates me.
Given that I'm a strong proponent of using the Operating System's features to solve problems, why wouldn't I like the idea of a local script using syslog to handle its logging? The biggest reason is that today's Solaris syslog facility remains tightly constricted in its use of facilities and levels. Yes, I'm well aware that syslog-ng can open those doors. I'm all for it! However, someone at Sun (Oracle) doesn't seem to be all for it yet, and I'm not a big fan of re-plumbing core OS features. So, until Sun sees the light and modernizes the syslog facility I believe in sticking with the standard.
One approach that may be acceptable is combining all Operational logging into a single facility. The trouble with that approach is that we have some logs which fall under tougher security policies than others, so you end up needing destination files with different attributes. So, what's the answer to the engineer's dilemma?
If an application needs to send its output for Enterprise-wide real-time processing for something like a log watcher, then it may be appropriate to use syslog in order to leverage its ability to forward log streams to syslog servers. But if you are writing a simple application which diligently generates log files for audit or troubleshooting purposes, you may be better off in the long run by writing a simple log function that dumps to a configurable destination file. Of course, your log files will be stored under /var/opt/something and will integrate with logadm(1M), right? Of course. After all, you are a Jedi...
Sunday, February 28, 2010
How about OpenJET?
I've had numerous occasions to "pop the hood" on JET to add functions or debug problems, and one of the things I appreciate is how it is implemented in well structured scripts. JET doesn't use complex frameworks or app servers just for the sake of adding "web 2.0" to a marketing slide. It's as simple as it needs to be. Bravo!
One thing I've noticed is that there's a HUGE amount of opportunity for enhancing JET, both in terms of optimizing existing code (increase use of functions, internal documentation, etc) but also in terms of enhancing functionality with new modules or new features in existing modules. Unfortunately, Sun (ahem, Oracle) is not really exploiting these opportunities in a timely manner. JET updates don't happen very frequently. I would expect that's due to economic strains impacting resources, and I don't expect the IT economy to suddenly produce a legion of JET developers.
Why not create an open community for the development of JET? There's all kinds of energy at OpenSolaris for next generation provisioning / packaging. If there were an OpenSolaris project for today's JET product I think we'd see it really take off. Many of us need to perform these enhancements either way, but we'd all benefit if we could leverage each others work and continue the evolution of a fantastic framework.
I'm hoping that resistance to opening JET isn't due to Sun Professional Services. JET is great, but it isn't rocket science. SunPS can always retain copyright or restrict distribution of their proprietary modules (as they always have). But the base framework screams to be open sourced, or turned into a community.
If Sun won't open the code it's tempting to try a black-box rewrite (I have no desire to break Sun's licensing - I respect their rights to code they developed!). It would certainly be a fun science project. Unfortunately, it would also be a waste of time given that an existing code base would make such a perfectly suited foundation.
So, how about it, Sun? OpenJET?
One thing I've noticed is that there's a HUGE amount of opportunity for enhancing JET, both in terms of optimizing existing code (increase use of functions, internal documentation, etc) but also in terms of enhancing functionality with new modules or new features in existing modules. Unfortunately, Sun (ahem, Oracle) is not really exploiting these opportunities in a timely manner. JET updates don't happen very frequently. I would expect that's due to economic strains impacting resources, and I don't expect the IT economy to suddenly produce a legion of JET developers.
Why not create an open community for the development of JET? There's all kinds of energy at OpenSolaris for next generation provisioning / packaging. If there were an OpenSolaris project for today's JET product I think we'd see it really take off. Many of us need to perform these enhancements either way, but we'd all benefit if we could leverage each others work and continue the evolution of a fantastic framework.
I'm hoping that resistance to opening JET isn't due to Sun Professional Services. JET is great, but it isn't rocket science. SunPS can always retain copyright or restrict distribution of their proprietary modules (as they always have). But the base framework screams to be open sourced, or turned into a community.
If Sun won't open the code it's tempting to try a black-box rewrite (I have no desire to break Sun's licensing - I respect their rights to code they developed!). It would certainly be a fun science project. Unfortunately, it would also be a waste of time given that an existing code base would make such a perfectly suited foundation.
So, how about it, Sun? OpenJET?
Sunday, February 07, 2010
Solaris Information Center: Release Naming
Why didn't I find this reference a long time ago? I even put a shell script in my home directory so I could dump releases whenever I needed it. Not any more. I'm moving that script into the cloud!
The Release Naming Matrix lists all of the Solaris releases and their associated maintenance updates. Very useful to anyone who manages a JumpStart / JET server, or maintains an Enterprise update process.
The Release Naming Matrix lists all of the Solaris releases and their associated maintenance updates. Very useful to anyone who manages a JumpStart / JET server, or maintains an Enterprise update process.
Wednesday, December 23, 2009
Free the Support Tools Bundle!
If you aren't already familiar with the Support Tools Bundle, you probably ought to check it out. It contains many very useful tools, at least one of which you absolutely need if you support more than one Solaris server.
I consider many of these tools to be critical components of our current Solaris architecture. As such, updating the tools is a part of our regular patch process. The tools are also integrated in our JumpStart JET templates. And herein lies my frustration.
You can only get the support tools as a bundle. If I want to get the latest SNEEP, I need to download the whole bundle. It's only ~ 40MB, so I can live with that given today's bandwidth. Unfortunately, when you unzip the shiny new file you are faced with something I consider a monstrosity. A shell archive. Why?
The next design flaw we encounter is the extraction method. The shell script exits unless you run it as root. If all I want to do is extract files, why should I be root? This undermines the principle of least privilege if I just need to put files in my home directory, or /var/tmp.
So let's assume we recklessly assume the role of root and execute the shell archive. We are presented with a choice to install or extract the files. Hopefully you want those files in /var/tmp/stb because that's your only choice. Again I ask, Why? Is there some flaw in using gzipped tar balls? I'm not a big fan of using zip, but it accomplishes a similar goal and would be acceptable.
How about a simple plan? Use a gzipped tarball that extracts one directory for each product and an installer in the root. That way I can just extract it and get the product updates into my JET server without having to go through an extra step. If you are skilled enough to know why you need the tools in STB, you can handle a tar.gz file. UNIX has survived the test of time by leveraging simplicity and standards. When we get too fancy we undermine the platform's greatest strengths.
As with any feature (and use of a shell archive is indeed a feature) we should ask the question, what is the value of this extra complexity? I would suggest the answer to that question is "none". Let's whack it and get back to standards, Sun.
I consider many of these tools to be critical components of our current Solaris architecture. As such, updating the tools is a part of our regular patch process. The tools are also integrated in our JumpStart JET templates. And herein lies my frustration.
You can only get the support tools as a bundle. If I want to get the latest SNEEP, I need to download the whole bundle. It's only ~ 40MB, so I can live with that given today's bandwidth. Unfortunately, when you unzip the shiny new file you are faced with something I consider a monstrosity. A shell archive. Why?
The next design flaw we encounter is the extraction method. The shell script exits unless you run it as root. If all I want to do is extract files, why should I be root? This undermines the principle of least privilege if I just need to put files in my home directory, or /var/tmp.
So let's assume we recklessly assume the role of root and execute the shell archive. We are presented with a choice to install or extract the files. Hopefully you want those files in /var/tmp/stb because that's your only choice. Again I ask, Why? Is there some flaw in using gzipped tar balls? I'm not a big fan of using zip, but it accomplishes a similar goal and would be acceptable.
How about a simple plan? Use a gzipped tarball that extracts one directory for each product and an installer in the root. That way I can just extract it and get the product updates into my JET server without having to go through an extra step. If you are skilled enough to know why you need the tools in STB, you can handle a tar.gz file. UNIX has survived the test of time by leveraging simplicity and standards. When we get too fancy we undermine the platform's greatest strengths.
As with any feature (and use of a shell archive is indeed a feature) we should ask the question, what is the value of this extra complexity? I would suggest the answer to that question is "none". Let's whack it and get back to standards, Sun.
Recommendations for you!
I just have to ask the question... Is anyone else who spends a LOT of time on Sun's web sites getting ready to rip out their fingernails when the site pops up the "Recommendations for you" box and forces you to close it? I'm a paying customer with a valid contract. I don't need to be treated like a mass marketing target.
The Internet provides great new business opportunity, and wild possibilities for creative marketing. But let's hope personal customer relationships which were once important haven't been replaced by marketing shotguns designed to bug 1,000 customers as long as one or two click on the shiny links.
Subscribe to:
Posts (Atom)
