Khamis, 21 Oktober 2010

Lupa root password

Aku rasa ramai org dah tahu mcm mana nak reset root dari grub. Tapi tak salah kalau aku nak share lagi dgn org lain yang masih belum tahu dan buat golongan pelupa (mcm aku).

Bagi siapa yang ada masalah lupa root password dan pelupa mcm aku jangan panik.. utk solve problem anda cuma beberapa steps sahaja sudah boleh selesai. Untuk menukar password root anda dikehendaki boot single user mode. Tapi itu pun kalau grub anda tak diset dgn password (bagus practise set grub password for security purpose).

Langkah-langkah:-

1. Boot sistem dan ketika anda melihat paparan berikut, tekan butang apa saja

2. Pada paparan berikut, tekan e

3. Selepas anda menekan butang [e] anda akan disajikan dengan paparan seperti dibawah.


3. select baris dengan vmlinuz di dalamnya dan tekan [e[. Layar berikutnya akan kelihatan seperti di bawah ini
4. type single seperti dibawah ini dan kemudian tekan enter.

4. GRUB akan boot single user mode Linux. Setelah selesai loading, anda akan disajikan dengan prompt shell seperti berikut:
5. Sekarang anda boleh menukar password root dengan menaip 'passwd root'

Anda akan diminta untuk ulang taip password untuk pengesahan. Apabila anda telah selesai, password akan berubah. Anda kemudiannya boleh reboot dengan menaip reboot pada prompt, kemudian anda boleh log in ke root seperti biasa.

Selasa, 19 Oktober 2010

HTTP time protocol

Hal berlaku disebabkan aku tak dpt nak sync semua time pada server2 yang ada di opis.. cek2 rupanya port 123 tcp/udp close... untuk rujukan yang tidak tahu tu.. port 123 ialah port utk NTP (Network Time Protocol).. mungkin ada sesetengah organisasi yang tak aware sangat issue time syncronization ni.. itu lantak depa laa.. but untuk aku masa adalah emas.. so rumusan dan andaian yang aku buat untuk budak2 network ni yang selalu port 123 NTP ni adalah seperti dibawah:-

- Mereka tidak tahu sedikit pun pasal NTP
- Mereka tidak tahu bagaimana pentingnya NTP
- Atau sebenarnya sudah ada local NTP server yang aku tak pernah tahu selama ni.. dimana aku kena sync dari server tersebut.. ianya sangat masuk akal untuk memiliki sebuah local NTP server.. tapi sepanjang aku kerja dkt malaysia ni... aku tak pernah jumpa company yang ada local NTP server... if banks, telcos, govs & MNC tu logic ada..

Dalam hal apapun, eloklah if korang bertanya kepada network team support jugak... (bertanya tak rugikan.. jika mereka sombong.. mereka yang bodoh..)

Jika diorang tak melayan permintaan kalian, aku cadangkan kalian cuba HTTP TIME PROTOCOL atas firerwall (outbound).. tapi diingatkan ia mungkin tidak setepat tho ntpd. setidak-tidaknya waktu dan tarikh anda tidak laa terlalu berbeza sgt kan?

Anda juga boleh mendapatkan HTP dari repositori.. selamat berjaya

Selasa, 28 September 2010

fw.proxy scripts

#!/bin/sh
# squid server IP
SQUID_SERVER="192.168.1.1"
# Interface connected to Internet
INTERNET="eth0"
# Interface connected to LAN
LAN_IN="eth1"
# Squid port
SQUID_PORT="3128"
# DO NOT MODIFY BELOW
# Clean old firewall
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
# Load IPTABLES modules for NAT and IP conntrack support
modprobe ip_conntrack
modprobe ip_conntrack_ftp
# For win xp ftp client
#modprobe ip_nat_ftp
echo 1 > /proc/sys/net/ipv4/ip_forward
# Setting default filter policy
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
# Unlimited access to loop back
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Allow UDP, DNS and Passive FTP
iptables -A INPUT -i $INTERNET -m state --state ESTABLISHED,RELATED -j ACCEPT
# set this system as a router for Rest of LAN
iptables --table nat --append POSTROUTING --out-interface $INTERNET -j MASQUERADE
iptables --append FORWARD --in-interface $LAN_IN -j ACCEPT
# unlimited access to LAN
iptables -A INPUT -i $LAN_IN -j ACCEPT
iptables -A OUTPUT -o $LAN_IN -j ACCEPT
# DNAT port 80 request comming from LAN systems to squid 3128 ($SQUID_PORT) aka transparent proxy
iptables -t nat -A PREROUTING -i $LAN_IN -p tcp --dport 80 -j DNAT --to $SQUID_SERVER:$SQUID_PORT
# if it is same system
iptables -t nat -A PREROUTING -i $INTERNET -p tcp --dport 80 -j REDIRECT --to-port $SQUID_PORT
# DROP everything and Log it
iptables -A INPUT -j LOG
iptables -A INPUT -j DROP

Isnin, 27 September 2010

Squid hostname error

[root@sawi squid]# less /var/log/squid/squid.out
[root@sawi squid]# vim squid.conf
[root@sawi squid]# service squid start
init_cache_dir /var/spool/squid... /etc/init.d/squid: line 62: 13530 Aborted $SQUID -z -F -D >> /var/log/squid/squid.out 2>&1
Starting squid: /etc/init.d/squid: line 42: 13532 Aborted $SQUID $SQUID_OPTS >> /var/log/squid/squid.out 2>&1
[FAILED]
---------------------------------------------------------------------
#add below line for above error

visible_hostname [your_hostname]

Jumaat, 17 September 2010

Informix DB backup into tape - shell script

Maaf lama menyepi tanpa sebarang update kerana saya baru sahaja joint syarikat baru. Banyak projek yang terpaksa saya laksanakan hinggakan tidak berkesempatan utk update isirung.

Di syarikat baru saya mengguna DB informix version 10 sebagai DB engine bagi applikasi disini. Jadi 1st day saya disini ialah menulis script seperti bagi tujuan backup dimana sebelum ini mereka melakukan backup secara manual.

DB engine: IBM Informix v10
OS: RHEL 4

------------------------------------------------------

#!/bin/bash

LEVEL=0
ontape -s <&1 >> /tmp/logfile
$LEVEL
read Return
EOF
exit

------------------------------------------------------

Jumaat, 5 Mac 2010

Puppet Show (Pertunjukkan Wayang)

Kelmarin saya hadir ke temuduga sebuah syarikat MNC dimana syarikat terbabit menyediakan perkhidmatan laman komuniti dan sosial bagi semua pengguna diseluruh dunia. Saya tertarik dengan satu soalan yang ditujukan kepada saya mengenai suatu senario.

"Bagaimana caranya saya melakukakan software automation pada pelayan yang berskala besar yang mana mempunyai high clustering level dan beratus server?"

Soalan ini ditujukan pada saya kerana syarikat terbabit mempunyai hampir 200 nix server di beberapa buah negara seperti di Sillicon Valley, London, Australia dan Singapore. Pengguna bagi laman komuniti syarikat tersebut juga mencapai beratus juta pengguna.

Berbalik pada soalan tadi, sejujurnya saya menjawab saya hanya melakukan prosedur biasa seperti melakukan UAT terlebih dahulu dan sekiranya semuanya selesai saya akan upload ke server dan melakukan rsync seperti biasa tanpa menggunakan sebarang applikasi komersil seperti OpsWare mahupun BladeLogic. Selain aplikasi komersil, ada juga aplikasi sumber terbuka seperti BCfg2, Cfengine dan Puppet. Cfengine ternyata telah menjadi pilihan utama bagi semua pentadbir sistem yang berskala besar sejak beberapa tahun ini an digunakan secara meluas di banyak syarikat-syarikat kecil mahupun besar. Namun sejak kemunculan Puppet (Wayang) ianya tampak lebih baik dari Cfengine kerana telah banyak mengatasi masalah yang ada pada Cfengine.

Jadi syarikat terbabit telah menggunakan Puppet sebagai software automation dan saya amat teruja melihat keupayaannya. Sejujurnya saya pernah terbaca artikel Puppet di majalah LFY (Linux For You) beberapa bulan lalu, cuma saya tidak berkesempatan untuk mencubanya. Saya benar² teruja untuk mencubanya pada pelayan ESX saya dirumah nanti.

Serba sedikit mengenai Puppet
Puppet ditulis didalam aturcara ruby dan dirilis dibawah GPL. Ini mendukung sejumlah sistem operasi seperti CentOS, Debian, FreeBSD, Gentoo, OpenBSD, Solaris, SuSE Linux, Ubuntu, dll. Puppet sekarang sedang digunakan oleh banyak organisasi termasuk Google, yang menggunakannya untuk menguruskan semua Mac desktop, laptop dan Linux klien . Senarai pengguna Puppet yang lain boleh diambil daripada http://reductivelabs.com/trac/boneka/wiki/WhosUsingPuppet.

Untuk entri yang akan datang saya akan cuba muatkan entri Howto Puppet. Terima kasih buat saudara Andy Ibrahim dengan soalan yang menarik itu. Suffer is not pain but its gain something that we never learn.. more pain more we gain experience

Rabu, 3 Februari 2010

Update PHP 5.3.1 on Centos 5.2

# Standard PHP version didalam Centos 5.2 agak ketinggalan dan untuk update menggunakan yum secara terus didapati mirror download yang sedia ada tidak melayan sebarang versi php yang terkini. Jadi dengan cara lain saya telah mengemaskini dahulu repositary yum dan baru laa saya melakukan update.


[root@ketutu ~]# wget http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm
--2010-02-03 14:37:45-- http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm
Resolving download.fedora.redhat.com... 209.132.183.67
Connecting to download.fedora.redhat.com|209.132.183.67|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 11989 (12K) [application/x-rpm]
Saving to: `epel-release-5-3.noarch.rpm'

100%[===========================================>] 11,989 27.3K/s in 0.4s

2010-02-03 14:37:48 (27.3 KB/s) - `epel-release-5-3.noarch.rpm' saved [11989/11989]

[root@ketutu ~]# wget http://rpms.famillecollet.com/enterprise/remi-release-5.rpm
--2010-02-03 14:38:01-- http://rpms.famillecollet.com/enterprise/remi-release-5.rpm
Resolving rpms.famillecollet.com... 88.191.60.189
Connecting to rpms.famillecollet.com|88.191.60.189|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4855 (4.7K) [application/x-rpm]
Saving to: `remi-release-5.rpm'

100%[===========================================>] 4,855 20.5K/s in 0.2s

2010-02-03 14:38:03 (20.5 KB/s) - `remi-release-5.rpm' saved [4855/4855]

[root@ketutu ~]# rpm -Uvh remi-release-5*.rpm epel-release-5*.rpm
warning: remi-release-5.rpm: Header V4 DSA signature: NOKEY, key ID 00f97f56
warning: epel-release-5-3.noarch.rpm: Header V3 DSA signature: NOKEY, key ID 217521f6
Preparing... ########################################### [100%]
1:epel-release ########################################### [ 50%]
2:remi-release ########################################### [100%]
[root@ketutu ~]# yum --enablerepo=remi update php
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* addons: centos.maulvi.net
* base: centos.maulvi.net
* epel: ftp.jaist.ac.jp
* extras: centos.maulvi.net
* remi: iut-info.univ-reims.fr
* updates: centos.maulvi.net
epel | 3.4 kB 00:00
epel/primary_db | 2.3 MB 00:13
remi | 2.6 kB 00:00
remi/primary_db | 185 kB 00:01
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package php.i386 0:5.3.1-1.el5.remi set to be updated
--> Processing Dependency: php-cli = 5.3.1-1.el5.remi for package: php
--> Processing Dependency: php-common = 5.3.1-1.el5.remi for package: php
--> Running transaction check
---> Package php-cli.i386 0:5.3.1-1.el5.remi set to be updated
--> Processing Dependency: libedit.so.0 for package: php-cli
--> Processing Dependency: php-common = 5.1.6-24.el5_4.5 for package: php-ldap
---> Package php-common.i386 0:5.3.1-1.el5.remi set to be updated
--> Running transaction check
---> Package libedit.i386 0:2.11-2.20080712cvs.el5 set to be updated
---> Package php-ldap.i386 0:5.3.1-1.el5.remi set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

===============================================================
Package Arch Version Repository Size
===============================================================Updating:
php i386 5.3.1-1.el5.remi remi 1.3 M
Installing for dependencies:
libedit i386 2.11-2.20080712cvs.el5 epel 79 k
Updating for dependencies:
php-cli i386 5.3.1-1.el5.remi remi 2.5 M
php-common i386 5.3.1-1.el5.remi remi 945 k
php-ldap i386 5.3.1-1.el5.remi remi 50 k

Transaction Summary
===============================================================
Install 1 Package(s)
Update 4 Package(s)
Remove 0 Package(s)

Total download size: 4.9 M
Is this ok [y/N]: y
Downloading Packages:
(1/5): php-ldap-5.3.1-1.el5.remi.i386.rpm | 50 kB 00:00
(2/5): libedit-2.11-2.20080712cvs.el5.i386.rpm | 79 kB 00:00
(3/5): php-common-5.3.1-1.el5.remi.i386.rpm | 945 kB 00:06
(4/5): php-5.3.1-1.el5.remi.i386.rpm | 1.3 MB 00:09
(5/5): php-cli-5.3.1-1.el5.remi.i386.rpm | 2.5 MB 00:18
------------------------------------------------------------------------------
Total 131 kB/s | 4.9 MB 00:38
warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID 00f97f56
remi/gpgkey | 1.3 kB 00:00
Importing GPG key 0x00F97F56 "Remi Collet " from /etc/pki/rpm-gpg/RPM-GPG-KEY-remi
Is this ok [y/N]: y
warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID 217521f6
epel/gpgkey | 1.7 kB 00:00
Importing GPG key 0x217521F6 "Fedora EPEL " from /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL
Is this ok [y/N]: y
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction

WARNING : This php-* RPM are not official Fedora build and
overrides the official ones. Don't file bugs on Fedora Project.

Use dedicated forums http://forums.famillecollet.com/

Updating : php-common 1/9
Installing : libedit 2/9
Updating : php-cli 3/9
Updating : php 4/9
Updating : php-ldap 5/9
Cleanup : php-common 6/9
Cleanup : php-cli 7/9
Cleanup : php 8/9
Cleanup : php-ldap 9/9

Dependency Installed:
libedit.i386 0:2.11-2.20080712cvs.el5

Updated:
php.i386 0:5.3.1-1.el5.remi

Dependency Updated:
php-cli.i386 0:5.3.1-1.el5.remi php-common.i386 0:5.3.1-1.el5.remi php-ldap.i386 0:5.3.1-1.el5.remi

Complete!
[root@ketutu ~]# php -v
PHP 5.3.1 (cli) (built: Nov 20 2009 17:51:14)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
[root@ketutu ~]# service httpd restart

Isnin, 11 Januari 2010

Disaster Recovery – What can happen and what would you do “if”?

Satu artikel yang menarik dari Chris Burdick utk dikongsikan pada kalangan System Administrator ataupun pada siapa yang berminat utk menceburi bidang IT..

With my roots in Systems Administration, Disaster Recovery or “DR” is a subject near and dear to my heart. However, I find that most people discount the importance of having a solid plan of what to do if the unexpected occurs.

When a person has a valuable asset, they never hesitate to insure it “just in case”. Yet with a website, which has inherent value and revenue potenial, the idea of insuring their site “just in case” never comes to mind. Unfortunately, it only takes a single mistake to wish that you had a DR plan. Many people will say, “We have a DR plan! What do you think those backups are for?” Unfortunately, having backups is not a DR plan. It is simply one of the counter measures that may come in handy when recovering from a disaster.

Let’s take a look at several scenarios when planning for DR:

Data Center

When choosing a hosting provider, always make sure that you have had the opportunity to review their data center locations. Ask about security, age of the facility, power redundancy, bandwidth provider and the address of the facility. It also never hurts to ask if you could take a tour of the facility. It is not so much that you are going to hop on a plane and visit, but if they deny the request entirely, you may want to keep shopping. This could be a sign of issues that they are trying to hide. Usually a claim of SOX / PCI Compliance and umbrella insurance documentation is enough to get a tour. It is not uncommon to require pictures of the location that is physically housing your server.
Mother Nature

So, Hurricane Jane just passed over your data center, leaving a rather sizeable hole in the ceiling.

Never underestimate the power of a storm. While this is more of a concern for your service provider, the end result is the same. If the hole is right above your server rack and water has penetrated your rack and hardware, your server will most likely be out of commission. If someone does not have a contingency plan for how the site will get up and running again, you may be out of business until services can be transferred to another data center or another server nearby. Hint: If your data center is located at the foot of an active volcano, in the most active segment of “tornado alley” or below sea level, you may want to put a little extra effort into your DR Plan (and consider moving).
Theft

John Doe, systems administrator extraordinaire, is doing routine maintenance in your rack. While he is taking his lunch break, he leaves the door open to your rack.

What would you do if someone stole a hard drive containing your entire customer database? While this does not happen every day…nothing in a Disaster Recovery plan does. Competition can be fierce…are YOU located in the same data center as your competitor? Physical theft of components not only means you need to replace the component (hard drive, SAN, backup device), but you also need to replace the data and find out who may have stole it in the first place.

Another reason to consider theft when planning is due to the location of most data centers. Some of the best Tier 1 provider data centers are located in the “bad parts of town” so to speak. Hosting requires 3 things: Space, Bandwidth, and Power. The cheaper the space, the higher their profit margin. Looking for places which have a nice balance between crime rate and the level of security of the facility are always worthwhile choices to house your data.

Also remember, if you are going to manage your own rack…do you want to get a call at 3 am and have to head to a high-crime area? You are now not only responsible for your equipment safety, but your own personal safety as well.
Power Outages

After a thunder storm, the main transformer leading into your data center is ‘fried’.

How redundant are the power sources in your data center? The best choice in a data center is one that provides redundant generators. Thus in the case of a power outage, your site will remain online during the repair to the data center.
Bandwidth Outages

During some routine upgrades, the main router for bandwidth control into your data center loses its configuration.

This is one that many people don’t think of. Does your data center provide you with redudant bandwidth sources? If their router is down, your site could end up down for hours while they restore the configuration.
Systems Administrators

John Doe, the systems administrator, runs updates on your server and performs a restart without authorization.

Did John discuss the update with your application team? Could one of these updates break the site? Perhaps your site requires configuration after a restart to fully configure a shared folder or other service you do not want started automatically. Regardless of the situation, John most likely took down your site. A proper DR plan accounts for situations like this which may not be apparent at first glance.
Application Support Team

Jane, one of your application developers, pushes an update to your site before headed out for the day. Having had a rough day, Jane turns off her phone and goes to bed early.

If Jane did not ensure that the update worked properly, the site could be down and no one knows it yet. Jane in particular, as she turned off her phone. This problem may persist until she makes it to work the next day.

This can usually be taken care of with an escalation system of some sort. In it’s simplest sense, it is a list of people to call in a hierarchical order. The more complex involves a system which allows a user to log a ticket and the system escalates the request automatically. Having proper procedures in place for application deployment can certainly help to alleviate this situation, but accidents do happen.
Novice User

Jake, a new user to your Content Management system, is asked to perform a cleanup task on some of the old articles.

This could end poorly for Jake and his boss. If Jake accidentally deletes articles or pages he was not supposed to, how will this content be retrieved?

Having appropriate backups of the database will certainly help in a situation like this. With a proper DR plan, Jake can simply call the appropriate person and the backups may even be restored before his boss finds out! This is good news for Jake and for the site as well.
Equipment Age

In an attempt to save money, John’s widgets puts his website up on a server with 5 year old hard drives. After a successful launch to their brand new website, their main hard drive fails bringing their online sales to a halt.

For anyone that doesn’t know, a hard drive’s life is measured using what is called “Mean-Time-To-Failure” or MTTF. It isn’t a matter of “IF”, it is a matter of “WHEN” the drive will fail. Their failure rates are normally within the first 3-4 months or 6-7 years. The 3-4 month range is due to design flaws and the 6-7 year is the life expectancy of the drive. Hard drives are devices which wear out and should be part of a cyclic hardware refresh program. Every year, a company who purchases and manages their own hardware should plan a portion of the budget to phase out old hard drives, upgrade ram and even upgrade servers over time. By replacing this equipment in a timely manner, a company can prevent server failures due to failing equipment.
Facilities

After a business in an adjacent office leaves a candle burning overnight, a fire spreads throughout the office complex burning all documents, equipment and leaving the widget of John’s widgets in shambles

While a DR plan should cover your servers, it should also cover disasters which may occur at your office locale as well. If your office building burned, was flooded or was closed due to an environmental contaminant…what happens? Does everyone have the rest of the month off while the office is repaired? In a good DR plan, there are clauses covering “continuing operations”. So all employees should know what happens if a disaster were to happen in the office building.

If something were to happen to an office building, the DR plan should lead a CEO / CIO to everything needed to restore operations as soon as possible. Situations such as unexpected equipment damage are why a “complete DR plan” will also include copies of all insurance policies, documentation of assets (all serial numbers with dates of purchase) and a plan to obtain replacement assets as soon as possible. It may also include a rendezvous point for any emergency meeting which may arise from a facility disaster.
Is that it?

Depending on your business domain, you may find that you have more issues to worry about than this. The best way to put together a DR plan is to have a brainstorm session with a diverse group from your company. At least one person from each department should chime in on what issues they can foresee. Once you’ve compiled issues like the examples above, appropriate counter-measures have to be planned for. This is where the actual plan may take the form of a dialog or flow-chart to handle any issues which may arise, in the appropriate manner.

Once a DR plan is made, it should be distributed to all employees or hosted in a location where everyone has access. An offsite copy should also be kept in case the digital version is destroyed.
Conclusions

Now you may be thinking, “Isn’t this a little excessive?” This sounds like a large investment of time and money! This is, in fact, true. A DR plan is a huge investment in protecting your company from the unforeseen. However, if your website goes down and all you have is ‘backups’, how long will it take you to get that site back up and running? Do you know what schedule the backups run on? Do you have hardware to replace the dead server or stolen equipment? Is your sole sysadmin on vacation for the next two weeks in Orlando? If your site goes down for even just a few hours, people lose faith in your brand. Particularly if you are in the IT industry in any shape or form. If you can’t keep your own equipment running, many people may doubt your ability to keep their equipment running properly as well. So the answer to excessiveness: How much is your brand worth to you?