G08 Is your DBA Paranoid Enough?
IDS 9.4 Recommended Security Practices
Jonathan Leffler, STSM, IBM Informix Database Engineering
IBM DB2 Information Management Technical Conference
Sept 20-24, 2004
Las Vegas, NV
Revised for KCIUG - Oct 27, 2004
DBSA - Database Systems Administrator
A paranoid DBSA keeps clients and server separate
- One INFORMIXDIR for clients
- One INFORMIXDIR for server
Does anyone actually use /usr/informix? (Omni does)
Jonathan uses symlinks...
/usr/informix/anabie23
symbolic link ->
/work3/informix/lastalled/ids-9.4.0.UC2
/work3/informix/lastalled/ids-9.5.0.UC5
Chunks: sym linked to devices in dev?
/informix/dev/anubis_23.rootdbs.c0 (m0 is mirror)
-> /dev/...
Only user informix should belong to group informix. Root, sure, but no users!
You must be able to trust group "bargroup". (People that can run the onbar utilities.)
"A paranoid DBSA doesn't like having to trust root", But they don't have much choice.
Always have all directories that Informix uses be protected directories. You can't use /tmp for anything, for instance, because someone could:
ln -s /etc/passwd /tmp/bar_debug.log
Now the onbar utilities are going to write a blank line into /etc/password and now they can log in as anyone?
Informix is going to come with a new thingy called the Bundle Installer which will do intelligent cross-package correction of stuff.
The mantra: "Turn off public writable permissions." Say it in your sleep.
After install establish a checksum for each file and keep the list. Then run checksum on the list, and keep the checksum for that elsewhere. "You will be paranoid. If you're not already, you will be before the end of this presentation."
GLS
ILS - International Language Supplement
Don't remove the en_US stuff. If all else fails, Informix tries to fall back to en_US.
oninit -ivy -- new server, one time only (-i is deadly!)
oninit -v -- upgrade
Understanding the Roles/Groups
- OSA: Operating System Administrator
- DBSA: db system administrator
- DBSSO: db system security officer
- AAO -- Audit Analysis Officer
- user 'informix', group 'informix'
- user 'root', group 'bargroup'
onaudit?? Dave says it sucks up disk space like crazy
Should the DBSA have OSA priiviledges ("root")?
- Some industries have legal requirements to seperate them
- Smaller organizations can't afford
You can have 100% encrypted database communication, but it puts a load on the database server. You have to config client end and server end. (You have been able to encrypt the username/password dialogue.)
Informixcan use PAM -- can AD use PAM?
If the application can handle challenge/response from PAM, then you can use Informix->PAM->key faub (number thingy)
9.4 new feature: You can configure the port of data replications ports vs. regular ports (and ER vs. HDR).
Alarm Program
- in 9.3 only handles log full
- in 9.4, handles everything. Can send emails, etc.
Mark Scranton
World Wide Technical Specialist
Informix Products
"One of the beautiful things about my job at Informix is that they let me do consulting too."
IDS 9.4: An "Under the Covers" Look at the Internals
- Work History: EDS, Ingres, Unify, Informix (1995-); IBM
- Publications:
- Contributor: "The Informix Handbook"
- IDS 9.x Certification test
markscranton.com
The New Job
- IBM Oct 1 2004
- World Wide Technical Specialist /
Informix Evangelist /
Informix Advocate for Informix Products
- Technical proofs/benchmarks/customer visits
- Mgmt Convincer
- Work w/ devel on new/uipcoming features
9.4: large chunks? What are those?
-------
a byte of data is in 1 page
a page is in 1 extent
an extent is in 1 tablespace
a tablespace is in 1 dbspace
a dbspace is in 1+ chunks
a chunk is on 1+ disks
LRU -- least recently used pages these should get written to disk as soon as possible.
MRU -- most recently used pages, these get written to disk last.
foreground writes -- when a user thread has to force the database to write because the data is still dirty.
background write -- LRU or checkpoints
"dirty pages" - pages that need to be written to disk
free page: not empty, but is free to be re-written
It does happen -- more index than data! 16 columns is max index per table.
you can set "set explain on" on the fly from onmode!
9.2 -> 9.3 250 bug fixes
9.3 -> 9.4
bloated indexes? onmode -pt
-------------
There's a topdb utility out there somewhere.
high cost doesn't necessarily mean bad performance, it could just be high cost
syssqexplain has a lot of data in it about performance
-------------
www.kazer.com -- free poster for sys* tables.
Had breakfast with James. Nice guy. He didn't offer me any silver bullet for GUI development, though. He worked with the Java struts guys, but the platform is bulky ("the 747 cockpit of GUI environments"). He confirmed that there probably is no stellar GUI environment for what we're doing.
Authored 2 J2EE specs
VP of Apache
Created Tomcat & ANT
He's published 4 books w/ O'Reilly.
Roadmap - Create Better Classes - Prefer composition - Design for inheritance - Program defensively - Program for Performance - Factories & abstraction - Other gotchas Preface Common Language Traits - Vocabulary (syntax) - Grammar (structure) - Usage
- Don't use public fields - Only use public fields for constants - All other fields should be private - Do use accessor methods - AKA JavaBeans methods - getProperty and setProperty Enforce Encapsulation Lock down utility classes - Java has no concept of functions - Utility functions can be collected as static methods in a utility class - Utility classes aren't meant to be instantiated -- so don't let them be. * example of class that explicitly defines the class name as a method so it can't be instatiated * Self Describing Objects - java.lang.Object defines the toString() method - prints a memory address reference (hey, just like Perl!) - Useless, so define a private toString method so it prints something useful instead. Prefer Composition over Inheritance A little analogy: - Inheritance = Robocop. - Composition = Knight Rider The point is that you can upgrade your classes without the risk of breaking everything in composition, with inheritance you run the risk of breaking everything. Inheritance requires detailed knowledge of class internals - Breaks encapsulation - Creates Code Fragility In the revision process do you stay true to the documented interface or do you stay true to the history of bug for bug compatibility? How to use Composition (aka Wrapping) - Make a new class - Hold instance of extended class privately - Existing class becomes a component - Forward methods from new to old class as appropriateBuild classes to use Delegation If you're building a Windows class, don't have people inherit your class to manipulate your (public) attributes to change you behavior. Instead, the delegation method is to allow users to send an object into your class to tell you what to do.
Design for Inheritance - Sometimes inheritance is the right tool to use. - When to use - Be sure to only inherit from classes you understand - Try to only inherit from classes you own or control - Be careful of "Standard" classes - Read the documentation for any class that you extend - Source code is the only way to understand the internals of a class - JavaDoc is neat idea, but isn't the end all be all solution for all documentation problems ever. - Document the effects of overriding each public or protected method."If you're the only one inheriting your classes, you can use inheritance all you want and everything is smokey dokey." But that's not how the real world works. Architect / plumber analogy when designing bathrooms.
- If you don't want to design for inheritance: - Finalize your classes (Finalize is a keyword that stops people from inheriting your classes.) .DLL hell JAR hell in Java world Gotchas - java.lang.Object's hashCode and equals are codependent methods - If you override one, be sure to override the other - Constructors should not invoke overridable methods - Overriden methods could break the constructor
- Your code will probably live a long life - It will be reused - It will be used in unexpected ways - It will be used on the network - It might get attacked - #1 Vulnerability: Parameters - Only assume sane data comes from internal methods - Package private or private methods - Never assume that you will get sane data on a public API - Make and enforce restrictions on prarameters - Range checking - Format checking - Type checking - Use IllegalArgumentException if data is not sane - Do not create your own home spun exceptions Mutable objects: You can change the attributes "There's only so much risk you can manage." - Multi-threaded applications increase vulnerabilities Use Immutable classes - Immutable classes, by definition, don't let instances be modified. - Instances have exactly one state - Easy to implement and test - Inherently thread safe - No worries about synchronization
- Understand Hotspot (some sort of optimization tool)
- His guys wrote Crimson, and different optimizer
xml.apache.org?
Java in memory lives in two different places:
Don't use exception handling for logic flow ever.
try {
while (true) { a[j++].0 }
} catch (someException) {
// do nothing
}
That's bad because the optimizer (HotSpot) is doing all sorts of extra work.
HotSpot is the default virtual machine, at least from any Sun Microsystems vendor.
Class clusters: - Implementations that vary behind a facade of a single class - Example: Windows and Unix versions of a Console class Factories and Abstraction (Avoid too much abstraction) - Your code runs on hardware - That hardware runs many programs - Class size and numbers increase lookup table sizes - There's only so much L1/L2/L3 cache available - After that, you're running at main memory speed. - Too much abstraction makes your code to hard to read and maintain. - There's a right level of abstraction. Find it and use it. What's the right level of abstraction? - It depends - Look to other domains and pick up clues on abstraction Math abstractions humans have found handy to invent over the centuries: - Numbers - Zero - Negatives - Real numbers - sqr root of 2 - sqr root of -1 = e - different types and sizes of infinityDon't try to solve too many problems in the future. Working on APIs most of the ways that he designed abstractions for future use were never used. Plus the way people use your code is inevitably not how you thought they would, so being in the business of predicting the future is a dangerous thing.
Other Gotchas Static method issues - Static methods are not subject to dynamic dispatch. - Finalizers (DESTROY) are not guarenteed to run at any particular time. - Dependent on the garbage collectiona algorithm - They may not run at all <-- under the Java virtual machine. - Language spec requires "best effort" - Exceptions thrown during finalization are ignored.Objects in Java will just hang out when they go out of scope! This is especially bad for database handlers and data streams
It was time for JDK 1.3 to be released. Microsoft had just announced Windows 2000, and the Sun marketing machine flew everyone in for a meeting and announced that JDK 1.3 would be marketed as Java 2000. They already had posters printed up and everything, but some engineers threatened to quit over the name change so they dropped the zeros: Java 2 (J2EE)
Servlets are the big thing. J2EE is overkill for 80% of stuff, and not good enough for half of the other 20%.
Java IDEs: jetbrains.com (Visual Age was always a JDK behind. Sun people never use an IDE because they're always on the next version of the JDK. -grin-) Featuritis is why all Java IDEs suck. And they're all free. Jetbrains costs a few hundred dollars.
SCO thing is a money grabbing scheme. The first people to pay up were Microsoft, so now SCO has lots of money to go after everyone else. Funny how that works.
Apache came from the motivated financial self interest of companies. Open source is really good for some tasks, really bad for others.
--- Highlights from OSCON 2003: Speaker Presentations, including links to Robert Lefkowitz's talks, "Protecting the Innovation Premium -- Open Source Business Models" and "The Missing Open Source Projects": http://conferences.oreillynet.com/pub/w/23/presentations.html Media Coverage and Photos: http://www.oreillynet.com/oscon2003/ Conference Program Archive: http://conferences.oreillynet.com/os2003/ ---
It occured to me that if our challenge is inbound parellelism, we could use Apache's threading / process control instead of trying to write our own. I spoke with Arthur later in the week and he agreed that that under a lot of conditions, Apache is obviously a viable solution for inbound connectivity.
For outbound applications we may want to look at rolling a threading template for hotel connectivity. Whenever we're connecting to all 38 properties and doing something, threads may help us get the job done *much* faster. Each Perl thread takes about 1MB of additional RAM, which is cheaper than running a seperate Perl process for each one, and probably lighter on our server, since most processing are just blocking waiting for DBI MS-SQL most of the time anyway? We'll need to benchmark it.
Simultaneous to this session was Up and Running With wxPython. I didn't learn what wx is until Friday -- we may want to look at wx as a possible alternative to VB.NET development. We could do wx development in many different languages, including Perl.
We've never had a testing suite of any kind at Omni. Now that we're getting a formal QA person, I'm becoming more conviced that we need to alter two fundamental areas of our software development cycle. The first of these was pounded into us over and over again in this session:
Test Suite
Design the Interface Before Writing any Code
This idea has always been fairly obvious to me. Had I been asked at any point over the last few years, I would have said that we should definately do this. Obvious, yes, but it just so happens that we haven't been doing it. We need to build this into our formalized process to ensure that this is, indeed, what actually happens in our development cycles. Probably one developer should develop the interface, let the other code the internals and test suite, and then both people review the code?
Depending on who you talk to, these techniques become a chunk of a full agile development suite of procedures and policies (I still need to type up my notes from the Midlands.NET meeting I went to a few weeks ago.) I'm not sold on the full-bore extreme programming model, but I think there are a few really good ideas we should give a thorough test to see if they work for our environment or not.
TRADITIONAL | AGILE Project Management Context | Control | Estimating | Scheduling -------------------|-X Iteration planning Requirements management | Team Roles -----------------------|-- Physical location Communication | Motivated individuals Meetings | Status --------------------|-X w/o documentation Progress ----------------/ | User/customer interaction | Configuration management | Change control | Release management | QA |