echo redhat-4 >> /etc/redhat-release in /etc/security/limits.conf # settings for oracle * soft nproc 2047 * hard nproc 16384 * soft nofile 1024 * hard nofile 65536 in /etc/sysctl.conf kernel.shmmni = 4096 /sbin/sysctl -p groupadd oinstall ; groupadd dba ; groupadd oper ; groupadd oracle useradd -g oinstall -G oracle -d /opt/oracle oracle passwd oracle install as user oracle... 11r1 & r2 install add'l packages setarch make glibc libaio compat-libstdc++ gcc libXp openmotif compat-db 11r2 yum install add'l packages: elfutils-libelf-devel gcc-c++ libaio-devel libstdc++-devel sysstat unixODBC-2.2.11 unixODBC-devel-2.2.11 pdksh
Monday, April 30, 2012
oracle 11r1 & r2 centos install notes
i don't like reading long docs. just distill it down you say?
okay.
Friday, April 27, 2012
dhcp3 combatting evil
After lunch yesterday I received a request for support from a fellow running several VMs and them not getting IP addresses from the DHCP server. That's weird. I've done nothing to my network and the ESX server looks just fine. There goes an afternoon...
After a look at the logs on the dhcp3 server, I found that an errant bank of devices was going haywire. Sure, pulling the power cord would've been a quicker fix, but I like puzzles.
Here's what I saw: first, a whole bunch of requests were coming in from a bunch of MACs pre-pended with e8:39:35 . All these requests were taking dhcp addresses. So, I plug in the address here:
http://www.wireshark.org/tools/oui-lookup.html
To figure out what hardware is behind that MAC.
I find out that it is not a virtual machine gone bad. HP device. Great. So then I pull out the bigger brain and decide that I want to craft a dhcp pool that'll ban HP devices and allow everything else. To do this I create rules explicitly allowing and denying classes of devices. Easy?
Below you'll find a list of common MAC identifiers for Virtual machines, a dhcp3.conf and some pertinent logs.
MAC identifiers
dhcp3.conf
Log snippet
After a look at the logs on the dhcp3 server, I found that an errant bank of devices was going haywire. Sure, pulling the power cord would've been a quicker fix, but I like puzzles.
Here's what I saw: first, a whole bunch of requests were coming in from a bunch of MACs pre-pended with e8:39:35 . All these requests were taking dhcp addresses. So, I plug in the address here:
http://www.wireshark.org/tools/oui-lookup.html
To figure out what hardware is behind that MAC.
I find out that it is not a virtual machine gone bad. HP device. Great. So then I pull out the bigger brain and decide that I want to craft a dhcp pool that'll ban HP devices and allow everything else. To do this I create rules explicitly allowing and denying classes of devices. Easy?
Below you'll find a list of common MAC identifiers for Virtual machines, a dhcp3.conf and some pertinent logs.
MAC identifiers
Company and Products MAC unique identifier VMware ESX 3/4 Server, Workstation, Player 00:50:56 00:0C:29 00:05:69 MS Hyper-V, Virtual Server, Virtual PC 00:03:ff Parallells Desktop, Workstation, Server, Virtuozzo 00:1c:42 Virtual Iron 4 00:0f:4b RedHat Xen 00:16:3e Oracle VM 00:16:3e XenSource 00:16:3e Novell Xen 00:16:3e Sun xVM VirtualBox 08:00:27
dhcp3.conf
ddns-update-style none; default-lease-time 600; max-lease-time 7200; authoritative; log-facility local7; option subnet-mask 255.255.255.0; option broadcast-address 10.10.10.255; option routers 10.10.10.1; option domain-name-servers 10.10.10.2, 10.10.10.3; option domain-name "my.company.com"; option netbios-name-servers 10.10.10.2; class "evil" { match if (binary-to-ascii (16,8,":",substring(hardware, 0, 4)) = "1:e8:39:35"); log (info, (binary-to-ascii (16,8,":",substring(hardware, 0, 4)))); } class "vmware-clients" { match if (binary-to-ascii (16,8,":",substring(hardware, 0, 4)) = "1:0:50:56") or (binary-to-ascii (16,8,":",substring(hardware, 0, 4)) = "1:0:c:29") or (binary-to-ascii (16,8,":",substring(hardware, 0, 4)) = "1:0:5:69"); log (info, (binary-to-ascii (16,8,":",substring(hardware, 0, 4)))); } class "not-evil" { match if not (binary-to-ascii (16,8,":",substring(hardware, 0, 4)) = "1:e8:39:35"); log (info, (binary-to-ascii (16,8,":",substring(hardware, 0, 4)))); } subnet 10.10.10.0 netmask 255.255.255.0 { pool { range 10.10.10.100 10.10.10.10.200; range 10.10.10.204 10.10.10.220; allow members of "vmware-clients"; allow members of "not-evil"; deny members of "evil"; } }
Log snippet
Apr 26 16:03:50 dhcpd: Wrote 8 leases to leases file. Apr 26 16:05:00 dhcpd: DHCPREQUEST for 10.10.10.175 from e8:39:35:1f:8a:6e via eth0: lease 10.10.10.75 unavailable. Apr 26 16:05:00 dhcpd: DHCPNAK on 10.10.10.175 to e8:39:35:1f:8a:6e via eth0 Apr 26 16:05:01 dhcpd: 1:0:50:56 Apr 26 16:05:01 dhcpd: 1:0:50:56 Apr 26 16:05:01 dhcpd: DHCPDISCOVER from 00:50:56:80:1a:75 via eth0 Apr 26 16:05:02 dhcpd: DHCPOFFER on 10.10.10.159 to 00:50:56:80:1a:75 (vmware-client01) via eth0 Apr 26 16:05:06 dhcpd: 1:0:50:56 Apr 26 16:05:06 dhcpd: 1:0:50:56 Apr 26 16:05:06 dhcpd: DHCPREQUEST for 10.10.10.159 (10.10.10.2) from 00:50:56:80:1a:75 (vmware-client01) via eth0 Apr 26 16:05:06 dhcpd: DHCPACK on 10.10.10.159 to 00:50:56:80:1a:75 (vmware-client01) via eth0 Apr 26 16:05:42 dhcpd: DHCPREQUEST for 10.10.10.162 from e8:39:35:1f:0e:97 via eth0: lease 10.10.10.162 unavailable. Apr 26 16:05:42 dhcpd: DHCPNAK on 10.10.10.162 to e8:39:35:1f:0e:97 via eth0 Apr 26 16:07:03 dhcpd: 1:34:40:b5 Apr 26 16:07:03 dhcpd: DHCPREQUEST for 10.10.10.172 from 34:40:b5:20:a8:01 via eth0 Apr 26 16:07:03 dhcpd: DHCPACK on 10.10.10.172 to 34:40:b5:20:a8:01 via eth0
Wednesday, April 18, 2012
fix arp caches
so yeah. your ipv4 forwarder may be all scrambled and you've flushed the arp cache per a previous post, but the switches still have the incorrect arp information and hilarity ensues. an easy way to fix this is to issue a network command from the machine affected by arp nastiness. here's a quick oneliner to use ssh to connect to somewhere else - in this case via an ip'd secondary nic:
ssh -b secondary.nic.ip.address -p port me@somewhereand the arp cache up the switch stack's been updated. of course, you're connecting to another system that's hanging off another switch up and around the stack, right?
Monday, April 16, 2012
who's plugging my ldap server
come on now. stop it already.
netstat -an | grep :389 | awk {'print $5'} | awk -F : '{print $1}' | sort | uniq
netstat -an | grep 389 | awk {'print $5'} | cut -f 1 -d \: | sort | uniq -cor. who the heck is searching for that freaking uid?
ngrep -q -t "uid" \(port 389 or port 636 \)
Tuesday, April 3, 2012
sunstudio11 curses!
sigh i messed up a studio11 install. i did. delete the directory, sure? and i did.
in the process of reinstalling, the installer said studio was already installed.
oh... yeah... pkgadd... whoopsies!
i need to reinstall. what to do?
From the commandline:
in the process of reinstalling, the installer said studio was already installed.
oh... yeah... pkgadd... whoopsies!
i need to reinstall. what to do?
Fixing a Failed Installation or Uninstallation on Solaris Platforms Become superuser by typing: su Password: root-password Open the Solaris Product Registry tool by typing: /usr/bin/prodreg & In the left pane of the tool, expand the Unclassified Software node. Select all of the package names containing Oracle Solaris Studio 11 and click Uninstall. Follow the instructions to remove the packages. Click Exit to exit the tool. Remove the /root/.nbi directory by typing: rm -r /.nbi
From the commandline:
# /var/sadm/prod/com.sun.studio_11/ # ./batch_uninstall_all
Subscribe to:
Posts (Atom)