Link : Solaris 10: Swap Space, /tmp and SMF

http://blogs.everycity.co.uk/alasdair/2008/12/solaris-smf-fixing-services-that-remain-disabled-after-being-enabled/

Link : Solaris 10 swap hakkında efsaneler ve gerçekler

Diyeceksiniz ki Solaris 11 çıktı sen hala 10'un swap'ı peşinde... Ne yapalım, ömür biter enterprise sistemlerin derdi bitmez. :)

http://blogs.oracle.com/jimlaurent/entry/solaris_faq_myths_and_facts

Motorsikletleri fark edin...

Catching disk latency in the act

Catching disk latency in the act:

Today, Brendan made a very interesting discovery about the potential sources of disk latency in the datacenter. Here's a video we made of Brendan explaining (and demonstrating) his discovery:

This may seem silly, but it's not farfetched: Brendan actually made this discovery while exploring drive latency that he had seen in a lab machine due to a missing screw on a drive bracket. (!) Brendan has more details on the discovery, demonstrating how he used the Fishworks analytics to understand and visualize it.

If this has piqued your curiosity about the nature of disk mechanics, I encourage you to read Jon Elerath's excellent ACM Queue article, Hard disk drives: the good, the bad and the ugly! As Jon notes, noise is a known cause of what is called a non-repeatable runout (NRRO) -- though it's unclear if Brendan's shouting is exactly the kind of noise-induced NRRO that Jon had in mind...

The specified channel could not be found. Check channel configuration. SCOM 2007

Diyelim ki, bir Windows 2008 R2 sunucuda "Applications and Services" altına konumlanmış yeni bir log kategorisinden bir olayı SCOM 2007 ile izlemek istiyorsunuz. Oturdunuz monitor de yazdınız...

Ama o ne ? Okuyamıyor logu, diyor ki ;

"The Windows Event Log Provider was unable to open the XXXX event log on computer 'rms.scomdomain.local' for reading.
The provider will retry opening the log every 30 seconds.

Most recent
error details: The specified channel could not be found. Check channel configuration."

Çözümü basit. Windows 2008 R2 sunucudaki Event Readers grubuna SCOM action hesabını eklediğinizde sorun çözülüyor.

expect aracının kullanımı. sftp / expect entegrasyonu

Bir iş için SFTP bir web sitesinden firmaddmmyy.firmaadi formatında dosya indirilmesi ve bunun rutin olarak yapılması istendi. FTP olsa kolaydı, bir shell scripti içinde alt alta komutları sıralayınca basitçe halledebilirdik ancak site yalnızca SFTP destekleyince işler karıştı.

SFTP ile yine argümanları sırasıyla ve ayrı ayrı göndermek mümkün ama iş kullanıcı adından sonra şifre göndermeye gelince SFTP mızıkçılık yapıyor. İzin vermiyor yani.

Bu durumda araya bir 'şey'in girip bu tür girdi bekleyen komutlara istediği cevabı göndermesi ve bunu da yine bir 'yığın' mantığıyla yapması gerekiyor. Gözüken buydu.

İşte burada 'expect' devreye giriyor. TCL diliyle entegre olan bu uygulama, bu tür ihtiyaçları karşılamak için birebir. Ancak Solaris için expect'i Sunfreeware.com'dan indirmek çok zahmetli. Bağımlılıklar can sıkıyor. OpenCSW'den indirmek daha kolay.

Expect'in detaylarına girecek değilim ama basit bir örnekle anlatmakta fayda görüyorum.


#!/opt/csw/bin/expect -f
# Asagidaki DOSYA_ADI degiskeni, sistem icinde tanimlaniyor. Olmadan calismayacaktir.


set timeout -1
spawn /usr/bin/sftp mahmure@veri.com
expect "password"
send "123456\r"
expect "sftp"
send "cd mahmure\r"
expect "sftp"
send "ls -l\r"
expect "sftp"
send "lcd /data/ftp/mahmure_local\r"
expect "sftp"
send "get $env(DOSYA_ADI)\r"
expect "sftp"


Aşağıda da bu konu hakkındaki enteresan linkler bulunuyor.

Automating sftp with expect script

http://jibbysununix.blogspot.com/2010/01/automating-sftp-with-expect-script.html

Scripting the OpenSSH, SFTP
http://www.scottklement.com/presentations/Setting%20up%20and%20Scripting%20the%20OpenSSH,%20SFTP%20and%20SCP%20Utilities%20on%20IBM%20i.pdf

SFTP Bash script with expect

http://www.admin-hints.com/2009/05/sftp-bash-script-with-expect.html

Automating SFTP using expect   
http://www.linux-bsd-central.com/index.php/content/view/26/
http://www.stratigery.com/scripting.ftp.html

OpenVAS yüklerken sertifikada patlarsa ? NO_PUBKEY BED1E87979EAFD54 W: You may want to run apt-get update to correct these problems

OpenVAS denemeleri yapıyordum. Laptopumda kurduğum Ubuntu 10.04 x64 sunucu üzerinde tüm güncellemeleri bitirdikten sonra sayfasındaki yönergeleri takip etmeye başladım.

http://www.openvas.org/install-packages.html#openvas4_ubuntu_obs

Ancak repository güncellemesi sırasında takıldık.

"Reading package lists… Done W: GPG error: http://download.opensuse.org ./ Release: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY BED1E87979EAFD54 W: You may want to run apt-get update to correct these problems"

Çözümü bir arkadaş bulmuş sağolsun.

http://www.christianweigel.com/113-installing-openvas-on-debian-lenny/

# sudo wget 

http://download.opensuse.org/repositories/security:/OpenVAS:/STABLE:/v4/Debian_5.0/Release.key

#sudo apt-key adv –import Release.key

#sudo apt-get update

Link : SCOM 2012 RC1 yayınlandı.

http://blogs.technet.com/b/server-cloud/archive/2011/11/10/system-center-operations-manager-2012-release-candidate-from-the-datacenter-to-the-cloud.aspx

Link : Solaris 11 belgeleri yayınlandı.

Dünden beri Mehmet Eroğlu'nun yeni kitabını okuyordum. Açıkçası uzun aradan sonra ME'den yeni bir kitap bana çok iyi gelmişti. Bayağı da ilerledim. Ama demin aşağıdaki haber geçti Facebook'tan. Solaris 11 belgeleri yayınlanmış.

Eh Oracle, bu bana yapılacak şey mi şimdi ? Hangisini okuyayım ben ? Patronuma söylesem de mesai saatlerini bir süreliğine okuma saatine mi çevirsem acaba ?

Solaris 11 hakkındaki tüm belgeler.
http://download.oracle.com/docs/cd/E23824_01/

Nasıl yaparım ? belgeleri
http://www.oracle.com/technetwork/systems/alltopics/index.html

Solaris 11 "Nasıl yaparım?" belgeleri
http://www.oracle.com/technetwork/systems/alltopics/s11collection-1356714.html

Link : Intrusion Detection using Solaris' Basic Security Module

http://www.symantec.com/connect/articles/intrusion-detection-using-solaris-basic-security-module

by David Endler

Introduction In our existing online world, intrusion detection has become a necessary expense. Not only does intrusion detection validate the effectiveness of border access controls (e.g., firewalls, screening routers, etc.), but it also helps combat the persistence of insider abuse and corporate espionage. For this reason, intrusion detection systems (IDSs) have become an essential component in creating any comprehensive network infrastructure. Intrusion detection systems rely on network traffic and/or system audit data as their main input sources. It is evident that an IDS can be only as powerful as the detail of the audit information fueling it. For instance, a host-based IDS monitoring only the syslog audit trail will be much less capable, than say, one that also examines /var/log/messages and the wtmp logs. One of the most information rich sources of audit information is the UNIX kernel. Kernel auditing is available in many flavors of UNIX, although some administrators shy away from enabling it. Three common reasons for hesitation are fears of cpu performance drain, not enough disk space, and not enough time available to comb through copious amounts of audit output. This article explains the value of kernel audit sources in host and hybrid-based intrusion detection systems. As an example, I demonstrate the built-in C2 kernel auditing features of the Solaris Basic Security Module, and present a few ideas for automating real-time misuse detection with it. What is C2? Most professionals in the Information Security world are well acquainted with the reality that until recently, UNIX was not designed with security as a priority. Over the years, the UNIX user base has shifted from "trusted" university and research environments to the commercial spectrum. In this shifting market, data security has taken on extreme importance. In the mid-eighties, the NSA NCSC published the Rainbow Series, a set of criteria used for evaluating the security features of computer systems. Security levels are defined in the "Orange Book" and are ranked from A1 (most trustworthy) to D (least). Stock UNIX's were roughly C1 (discretionary security protection) and could be upgraded with few headaches to C2 (added auditing capability and increasing access control). Operating system vendors at the time relied significantly more on government contracts than in today's dot.com market. For that reason, there was an effort to ensure that products were evaluated against the C2 criteria, so as not to preclude potentially lucrative government business. As a result, vendors tended to allocate as few resources as they could toward developing auditing capability while still giving the appearance of C2 compliance. Today, most of these original developers have moved on to other projects, and in many cases, to new companies. This Isn't Your Mother's C2 Kernel auditing has gradually been integrated as a feature into various flavors of UNIX over the past decade. Kernel audit trails differ from other types of audit sources in that they are generated internally by the kernel and are often stored in some sort of binary format, consequently making them tedious to tamper with. Most other audit sources (e.g., syslog, sulog, etc.) are the outputs of specific applications and are stored in plain ASCII format, making them more susceptible to alteration by an intruder in order to hide malicious behavior. Sun first distributed C2 compliant kernel auditing capabilities with a patch for SunOS 4.1.2 called C2Conv. This shell script enabled features that met all government C2 criteria, but was difficult to use. Under development at the time was Solaris (SunOS 5.x) which had a much better audit subsystem. Sun put out another patch for SunOS 4.1.3 that used this yet-to-be-released Solaris kernel auditing. When it was finally released, Solaris included the improved Basic Security Module (BSM) which had yet another C2 audit subsystem. As a result, there are three Sun auditing variants that meet C2 criteria: 2 patches (SunOS 4.1.2 BSM and SunOS 4.1.3 BSM) and the built in kernel auditing under the Solaris BSM. The look and feel of the Solaris BSM has not changed since it first debuted almost 10 years ago. The Solaris Basic Security Module The Basic Security Module (BSM) has been integrated into all versions of Solaris, and contributes just two things to the OS: kernel auditing and a device allocation mechanism. These two features when properly used in conjunction with the standard built-in security of Solaris, meet C2 level criteria. What does this mean to you? Probably nothing. The point is that BSM's kernel auditing feature is a powerful standalone tool that can serve as the data source to a variety of host and hybrid-based IDSs. Many system administrators are unaware of this powerful auditing capability in Solaris. Many others are turned off by the lack of helpful BSM documentation, manuals which have not changed much since they were first published almost 10 years ago. BSM includes some built-in utilities (e.g., praudit, auditreduce, etc.) for converting the raw binary audit trails into human-readable format, although Sun's Solaris Answerbook provides little guidance for monitoring intrusive behavior, except to say: You can accomplish more sophisticated display and reporting by postprocessing the output from praudit (withsed or awk, for instance) or by writing programs that interpret and process the binary audit records. The following steps will help you enable and configure BSM for use as input to any number of homegrown or commercial IDSs. Enabling and Configuring BSM To enable the Basic Security Module, go into the /etc/security directory and run the script bsmconv. # cd /etc/security # ./bsmconv This script is used to enable the Basic Security Module (BSM). Shall we continue with the conversion now? [y/n] y bsmconv: INFO: checking startup file. bsmconv: INFO: move aside /etc/rc2.d/S92volmgt. bsmconv: INFO: turning on audit module. bsmconv: INFO: initializing device allocation files. The Basic Security Module is ready. If there were any errors, please fix them now. Configure BSM by editing files located in /etc/security. Reboot this system now to come up with BSM enabled. # Next, let's take a look at the file /etc/security/audit_control: #ident @(#)audit_control.txt 1.3 97/06/20 SMI # dir:/var/audit flags:all minfree:20 naflags:lo This file determines how auditing will behave. The following flags are described: dir - specifies the directory to write the binary audit trails. You can put more than one dir directive in the file, which tells BSM where to start writing audit trails once the first directory fills up. flags - specifies the types of actions to audit. The complete list of possible "audit classes" includes: FLAG LONG NAME SHORT DESCRIPTION no no_class null value for turning off event preselection fr file_read Read of data, open for reading, etc. fw file_write Write of data, open for writing, etc. fa file_attr_acc Access object attributes: stat, pathconf, etc. fm file_attr_mod Change object attributes: chown, flock, etc. fc file_creation Creation of object fd file_deletion Deletion of object cl file_close close(2) system call pc process Process operations: fork, exec, exit, etc. nt network Network events: bind, connect, accept, etc. ip ipc System V IPC operations na non_attrib non-attributable events ad administrative administrative actions: mount, exportfs, etc. lo login_logout Login and logout events ap application Application auditing io ioctl ioctl(2) system call ex exec exec(2) system call ot other Everything else all all All flags set minfree - specifies the minimum total percentage of free space available in the audit directories. If the threshold falls below the number indicated (in this case 20%), then the script /etc/security/audit_warn is run which should be configured to either email the system administrator, automatically zip and archive existing logs, etc. naflags - specifies which audit classes are to be logged when the system events can not be attributed to a specific user. For the purposes of our example, the audit_control flags line should be edited to read: flags:ex,pc The file /etc/security/audit_user can be used to add more granularity for certain users (by default, root login information is always monitored). Now, reboot the system. The next time Solaris comes up, C2 auditing is enabled and your audit directory should look something like this: # ls /var/audit 20000601074538.not_terminated.localhost # Each time you restart the system, or stop and start the audit daemon, a new audit file is created with the timestamp in its name. For instance, the above audit trail was created on June 01, 2000 at 07:45:38 local time. The "not_terminated" signifies either the audit daemon was interrupted before it could close the file gracefully (system crash), or it is the actual real-time audit trail currently being appended. To be sure, check in /etc/security/audit_data for the name of the audit trail currently in use by BSM. To monitor the audit trail in real-time, try this: Bring up two shell terminals in your favorite windowing system In one of the shell windows, type (substitute the name in /etc/security/audit_data after tail -0f): # tail -0f /var/audit/20000601074538.not_terminated.localhost | praudit In the other shell window, start typing commands such as: #finger #ls #cd /etc #perl -v The other window will show something similar to: file,Thu 01 Jun 2000 09:59:38 PM EDT, + 391003 msec, header,111,2,execve(2),,Thu 01 Jun 2000 09:59:41 PM EDT, + 220000000 msec path,/usr/bin/finger attribute,100555,root,bin,26738688,74333,0 subject,root,root,other,root,other,648,281,0 0 localhost return,success,0 header,61,2,exit(2),,Thu 01 Jun 2000 09:59:41 PM EDT, + 240000000 msec subject,root,root,other,root,other,648,281,0 0 localhost return,success,0 header,79,2,fork(2),,Thu 01 Jun 2000 09:59:57 PM EDT, + 860000000 msec argument,0,0x289,child PID subject,root,root,other,root,other,580,281,0 0 localhost return,success,0 header,107,2,execve(2),,Thu 01 Jun 2000 09:59:57 PM EDT, + 860000000 msec path,/usr/bin/ls attribute,100555,root,bin,26738688,74378,0 subject,root,root,other,root,other,649,281,0 0 localhost return,success,0 header,61,2,exit(2),,Thu 01 Jun 2000 09:59:57 PM EDT, + 880000000 msec subject,root,root,other,root,other,649,281,0 0 localhost return,success,0 header,100,2,chdir(2),,Thu 01 Jun 2000 10:00:07 PM EDT, + 470000000 msec path,/etc attribute,40755,root,sys,26738688,7425,0 subject,root,root,other,root,other,580,281,0 0 localhost return,success,0 header,79,2,fork(2),,Thu 01 Jun 2000 10:00:23 PM EDT, + 0 msec argument,0,0x28a,child PID subject,root,root,other,root,other,580,281,0 0 localhost return,success,0 header,109,2,execve(2),,Thu 01 Jun 2000 10:00:23 PM EDT, + 330000000 msec path,/usr/bin/perl attribute,100555,root,bin,26738688,137497,0 subject,root,root,other,root,other,650,281,0 0 localhost return,success,0 header,61,2,exit(2),,Thu 01 Jun 2000 10:00:23 PM EDT, + 840000000 msec subject,root,root,other,root,other,650,281,0 0 localhost file,Thu 01 Jun 2000 10:00:41 PM EDT, + 30217 msec, Anatomy of a BSM Audit Event As you can see from the output above, the meanings of the records produced by BSM auditing are not entirely self-evident. Here is a brief run-down of how BSM audit records are generally structured. Each user-level and kernel event record has at the very least the following tokens: Header Subject Return Each event will begin with a "header" which will be in the format: header, record length in bytes, audit record version number, event description, event description modifier, time and date The "subject" line is of most interest to us when monitoring for unauthorized privilege escalation. Each subject line is in the form of: subject, user audit ID, effective user ID, effective group ID, real user ID, real group ID, process ID, session ID, and terminal ID consisting of a device and machine name Notice the changes that occur in the audit subject lines when the user endler performs a buffer overflow attack using the Xsun vulnerability in Solaris x86. The local attack: $ whoami endler $ ./a.out Jumping to Address 0xefffcc08 # whoami root generates the following in the audit trail: header,73,2,old setuid(2),,Thu 01 Jun 2000 01:59:31 AM EDT, + 860000000 msec header,103,2,execve(2),,Thu 01 Jun 2000 01:59:41 AM EDT, + 540000000 msec path,/tmp/a.out attribute,100755,root,other,26738688,329,0 subject,endler,endler,other,endler,other,696,688,0 0 localhost return,success,0 header,117,2,execve(2),,Thu 01 Jun 2000 01:59:41 AM EDT, + 550000000 msec path,/usr/openwin/bin/Xsun attribute,104775,root,bin,26738688,167114,0 subject,endler,root,other,endler,other,696,688,0 0 localhost return,success,0 header,61,2,exit(2),,Thu 01 Jun 2000 01:59:41 AM EDT, + 600000000 msec subject,endler,root,other,endler,other,696,688,0 0 localhost return,success,0 header,79,2,fork(2),,Thu 01 Jun 2000 01:59:48 AM EDT, + 300000000 msec argument,0,0x2b9,child PID subject,endler,endler,other,endler,other,690,688,0 0 localhost return,success,0 header,104,2,execve(2),,Thu 01 Jun 2000 01:59:48 AM EDT, + 300000000 msec path,/tmp/ksh attribute,100555,root,other,2,472011600,4294967295 subject,endler,root,other,endler,other,697,688,0 0 localhost return,success,0 header,61,2,setpgrp(2),,Thu 01 Jun 2000 01:59:48 AM EDT, + 310000000 msec subject,endler,root,other,endler,other,697,688,0 0 localhost return,success,688 header,61,2,setpgrp(2),,Thu 01 Jun 2000 01:59:48 AM EDT, + 310000000 msec subject,endler,root,other,endler,other,697,688,0 0 localhost return,success,688 header,61,2,setpgrp(2),,Thu 01 Jun 2000 01:59:48 AM EDT, + 310000000 msec subject,endler,root,other,endler,other,697,688,0 0 localhost return,success,0 header,61,2,setpgrp(2),,Thu 01 Jun 2000 01:59:48 AM EDT, + 310000000 msec subject,endler,root,other,endler,other,697,688,0 0 localhost return,success,688 The detection of an attack in this sequence is subtle. The subject line in question (outlined in red) illustrates a buffer overrun attack because the effective user ID (third field) becomes root. The significance of this line, as compared to the subject lines outlined in blue, is that the program that was executed (in this case /tmp/ksh) is not a setuid program so there is no reason that the user endler should have root permissions while running it. We can determine the default permissions on the file /tmp/ksh by translating the attribute field (outlined in purple) to -r-xr-xr-x user:root group:other In contrast, the Xsun program is a root owned setuid program which can be extrapolated from the attribute token (outlined in green). The fields in the green attribute line describe the file attributes of the Xsun executable and the appropriate permissions block can also be translated to (notice the setuid bit): -rwsrwxr-x user:root group:other This means that a transition to root privilege as shown in the effective user ID field (blue lines) is normal when a user runs this program. Many root-owned setuid programs (e.g. ps, quota, etc.) will appear to show the same behavior as Xsun and must be factored into detection scripts so false positives do not occur. A nice perl script that will automatically do all of this detection for you is St. Jude, by Tim Lawless. A similar set of perl scripts by the author can be found here that go along with the article Detecting Illegal Root Transition in Solaris in Sys Admin: The Journal for UNIX Systems Administrators, 7(8), p. 29-32, 34--35, August 1998. Other Ideas for Detecting Abuse Monitoring the effective user ID field in the BSM audit trail is only one method for detecting potential system abuse. Using the configuration listed above, you can also look for other types of warning signs that a machine may have been compromised or that an insider is misusing his privileges. Certain system directories (e.g., /etc/security, /var/log, etc.) may offer signs of malicious intent when someone tries to access them. Even when users fail to access a directory, it will still show up in the audit trail. For instance, the following is a snippet from a user changing directories to /var/log. header,97,2,chdir(2),,Thu 01 Jun 2000 03:26:34 AM EDT, + 430000000 msec path,/var/log attribute,40755,root,root,26738688,2,0 subject,endler,endler,other,endler,other,754,752,0 0 localhost return,success,0 The "path" token shown above can also be quite useful in monitoring executables. There have been many papers written on the behavior patterns of online miscreants in relation to the types of programs they are likely to execute. For instance, an attacker will most likely use the finger or w command to ensure no administrators are logged in. He will then probably scan the process table for any suspicious logging mechanisms (such as BSM) that may retain evidence of his actions. The possible scenarios are endless, although simple sequences of commands can be easily scanned for in the audit trail in real-time (see USTAT by Koral Ilgun). Even single instances of execution may signal future attacks, such as a user trying to execute commands such as ufsrestore or sudo. header,108,2,execve(2),,Thu 01 Jun 2000 03:26:34 AM EDT, + 450000000 msec path, /usr/sbin/ufsrestore attribute,100555,root,root,26738688,74360,0 subject,endler,endler,other,endler,other,754,752,0 0 localhost return,success,0 Conclusion UNIX kernel audit data is one of the most overlooked sources for intrusion detection systems. Understanding the audit subsystem on your UNIX machine should be one of the very first priorities of any security or system administrator. Simple host and hybrid-based IDSs can incorporate a kernel audit trail once an effective preprocessing method has been established (e.g., perl, c-shell, etc.). In addition to Solaris, other UNIX flavors that support kernel auditing include HP-UX 10.x, AIX, and DG-UX 4.12T. Unfortunately, there is not much homogeneity to these audit trail formats. There is however a Basic Security Module patch for Linux that behaves nearly the same as its Solaris C2 counterpart. Until the Common Intrusion Detection Framework (CIDF) becomes more accepted among OS vendors and security professionals, there seems to be no easy fix in the near future for integrating all of these different audit sources into IDSs. David Endler is a Senior Security Engineer for iDEFENSE, Inc., a company specializing in cyber-threat intelligence. He holds a B.S. and M.S. in Computer Science, and enjoys participating in research on intrusion detection systems that incorporate artificial intelligence.

Relevant Links Subscribe to the FOCUS-IDS Mailing List SecurityFocus.com Solaris Security Sun Microsystems Intrusion Detection FAQ SANS Institute

This article originally appeared on SecurityFocus.com -- reproduction in whole or in part is not allowed without expressed written consent.

/usr/lib/security/audit_binfile.so.1 retry all partitions full

Solaris 10 sunucusunda Solaris audit (auditd) loglarını sysloga yönlendirme testleri yapıyordum. Konfig dosyasını değiştirdikten sonra audit servisini yeniden açtım. Testten sonra kapamıştım ve bir süredir kapalıydı. Ama o ne ?


/usr/lib/security/audit_binfile.so.1 retry all partitions full This message has been displayed 4 times.


mesajı geliyor servisten her logladığı komut için.


Sorun şu ; audit loglarını yönlendirdiğim klasörü silmişim. Sistem boşu boşuna bu klasörü arıyor konfig dosyasının içinden okuyarak. 


Klasörü yeniden açınca sorun kalmadı. Ancak hala istediğim sonucu elde edemedim. Onun da bilgisini ve detayını sonra yazacağım.

Solaris 10, başka syslog sunucusuna yönlendirmek

İster inanın , ister inanmayın ; Google'da Solaris 10 sunucusunun sysloglarını başka bir sunucuya yönlendirmeyle ilgili bilgi aradığınızda ilk 3-5 sayfada dişe dokunur bir bilgi gelmiyor.


Bu aslında Internet'in bize sağladığı mı diyelim yoksa başımıza sardığı mı ; ciddi bir üşengeçlik ve araştırmacı ruh zehirlemesi.


Bu bilgi zaten /etc/syslog.conf içinde duruyor. :) Ah Google...


Biraz daha işe yarar bilgi ekteki blogda var.


http://woss.name/2007/06/17/solaris-logging-to-a-separate-loghost-the-easy-way/


Örnek konfig aşağıda ;


user.debug                                              ifdef(`LOGHOST', /var/log/syslog.user, @loghost)
kern.info                                               ifdef(`LOGHOST', /var/log/syslog.kernel, @loghost)
daemon.info                                             ifdef(`LOGHOST', /var/log/syslog.daemon, @loghost)
auth.info                                               ifdef(`LOGHOST', /var/log/syslog.auth, @loghost)
cron.info                                               ifdef(`LOGHOST', /var/log/syslog.cron, @loghost)
audit.info                                              ifdef(`LOGHOST', /var/log/syslog.audit, @loghost)

SCOM sunucusunun fizikselleştirilmesi ve veritabanının taşınması

Mevcut SCOM sunucularımız yoğun veri akışı nedeniyle artık zorlanıyordu ve konsolu kullanmakta güçlük çekiyorduk. Bunun üzerine veritabanını bir fiziksel sunucuya taşıyıp ardından da RMS rolünü üzerine çekmeye karar verdik.​


Mevcut yönergeleri okuyunca basit görünen bir iş, bizim ortamda da çok sorun çıkartmadı. Kısaca adımları sıralayacak olursak ;

1. SCOM sunucularındaki servisleri sustur.
2. Veritabanını 'detach' et. Diğer SQL cümleciklerini yazmıyorum, yönergede var.
3. Veritabanı sunucusundan SCOM DB rolünü kaldır (Uninstall)
4. Daha önceden kurulmuş yeni DB sunucusuna veritabanını kopyala ve bağla. Bu adımda biz mevcut SQL 2005'teki veritabanını SQL 2008 SP2'ye sorunsuz bağlayabildik.
5. Tüm SCOM sunucularında MS yönergesinde belirtilmiş kayıt defteri anahtarını değiştir.
6. Yeni SQL sunucusunda SCOM için gerekli hesapları ekle. Ekleyince veritabanı üzerinde yetkileri otomatik tanıyor.
7. SCOM sunucularını sırayla kapat aç.
8. Eğer 33333 hata kodu alınırsa (senaryoya da uyuyorsa) ikinci yönergeyi uygula.
9. Bu adımda artık çalışmış olmalı.

MS yönergesi

http://technet.microsoft.com/en-us/library/cc540384.aspx

33333 hatası alındığında uygulanacak yöntem.

http://opsmgradmin.blogspot.com/2011_05_01_archive.html


sp_configure @configname=clr_enabled, @configvalue=1
GO
RECONFIGURE
GO

Aldığımız hata mesajı

Link : 11 Reasons Why Oracle Solaris 11 11/11 Isn't Being Released on 11/11/11

http://blogs.oracle.com/solaris/entry/11_reasons_oracle_solaris_11

So here's why we didn't go with that date.  (Two of these are actually the real reasons.)

1. Whoa -- we never thought of that!
2. We just couldn't wait.
3. Friday -- not a good day for a product launch.
4. Armistice Day/Remembrance Day/Veterans Day -- not a good day for a product launch.
5. Sony Pictures begged us not to release on the same day as the new Adam Sandler movie.
6. We figured the launch parties would keep going for three days.
7. Dysnumeria.  (This does not appear to be an actual word.)
8. Hoping to ride the coattails of the commemorations of Louis the Bavarian's defeat of his cousin Frederick I of Austria at the Battle of Gamelsdorf in 1313.
9. "11" is actually 9--in octal.  OK, that one's exceptionally weak.
10. November 9 is Inventors' Day!  (Which is held on this day because it's the birthday of actress Hedy Lamarr, who invented frequency-hopping spread spectrum signalling in 1942.  I am not making this up.)
11. "No... that's just what they'll be expecting us to do."

Link : Solaris öldü mü ? Solaris 11 Ölü bir yatırım mı ?

http://medianetwork.oracle.com/video/player/1218920897001