howto get access ilo’s “Direct terminal access” via Serial Console

hi. so you’ve got some HP DL’s (like dl380 … ) servers and you’ve setup ilo to get access to terminal.

after you enabled ssh remote access (it is enabled by default) for ilo run this :

# ssh <user>@<ilo-ip-address>

</>hpiLO-> TextCons

maybe your terminal freezzzz . so in os you should add this line in /etc/default/grub :

GRUB_CMDLINE_LINUX_DEFAULT=”vga=normal nomodeset 3″

# update-grub

# reboot

then try again.

BTW : i’ve got some nice tutorial to enable serial console for virtual machines here .


How to setup Sony SNC-EP521 with pan tilt zoom


hi. this is the mini project i’ve done for my zoneminder servers. unfortunately couldn’t find any tutorial zoneminder-logoto enable sony network camera for zoneminder. so used some other source code and changed code to enable sony snc-ep521 ptz.

you can find source code here ,and some wiki to enable pan, tilt, zoom and presets.

hopes helpful.

some notes about IO schedulers

1. To choose IO schedulers at boot time, use the argument ‘elevator=deadline’.
‘noop’ and ‘cfq’ (the default) are also available. IO schedulers are assigned
globally at boot time only presently.

2.  The list of defined schedulers can be found by simply doing :
cat /sys/block/<device>/queue/scheduler

3. To set a specific scheduler, simply do this:
echo SCHEDNAME > /sys/block/DEV/queue/scheduler
where SCHEDNAME is the name of a defined IO scheduler, and DEV is the
device name (hda, hdb, sga, or whatever you happen to have).

4. to update scheduler via grub:
Edit /etc/default/grub, such as gksudo gedit /etc/default/grub, here you need to add elevator=noop .

Change GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash” to GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash elevator=noop”.

Then run sudo update-grub2 and restart.

# cat /sys/block/hda/queue/scheduler
noop deadline [cfq]
# echo deadline > /sys/block/hda/queue/scheduler
# cat /sys/block/hda/queue/scheduler
noop [deadline] cfq

which scheduler ?
this is what i’ve found by searching so far but not tested:
1. Noop:   if your system is CPU-bound and the storage is fast
2. cfq : is good for most of workloads. even databases.
3. Deadline :  recommended for databases  by linux kernel documentation

basic concepts:

Linus Elevator :
such as the one taken by the 2.4 Linux kernel’s I/O scheduler, the Linus Elevator—is to simply stop insertion-sorting if there is a sufficiently old request in the queue. This trades overall performance for per-request fairness and, in the case of reads, improves latency. The problem is that this heuristic is a bit too simplistic. Recognizing this, the 2.6 Linux kernel witnessed the demise of the Linus Elevator, and unveiled several new I/O schedulers in its place.

Deadline I/O Scheduler:
was introduced to solve the problems with the 2.4 I/O scheduler, and traditional elevator algorithms in general. The Linus Elevator maintains a sorted list of pending I/O requests. The I/O request at the head of the queue is the next one to be serviced. The Deadline I/O Scheduler keeps this queue, but kicks things up a notch by introducing two additional queues: the read FIFO queue, and the write FIFO queue. The items in each of these queues are sorted by submission time (effectively, the first in is the first out). The read FIFO queue, as its name suggests, contains only read requests. The write FIFO queue, likewise, contains only write requests. Each request in the FIFO queues is assigned an expiration value. The read FIFO queue has an expiration time of 500 milliseconds. The write FIFO queue has an expiration time of five seconds.
When a new I/O request is submitted, it is insertion-sorted into the standard queue, and placed at the tail of its respective (read or write) FIFO queue. Normally, the hard drive is sent I/O requests from the head of the standard sorted queue. This maximizes global throughput by minimizing seeks, as the normal queue is sorted by block number (as with the Linus Elevator).
When the item at the head of one of the FIFO queues grows older than the expiration value associated with its queue, however, the I/O scheduler stops dispatching I/O requests from the standard queue, and begins servicing requests from that queue—the request at the head of the FIFO queue is serviced, plus a couple of extras for good measure. The I/O scheduler needs to check and handle only the requests at the head of the queue, as those are the oldest requests.
In this manner, the Deadline I/O Scheduler can enforce a soft deadline on I/O requests. Although it makes no promise that an I/O request will be serviced before its expiration time, the I/O scheduler generally services requests near their expiration times. Thus, the Deadline I/O Scheduler continues to provide good global throughput without starving any one request for an unacceptably long time. Because read requests are given shorter expiration times, the writes-starving-reads problem is minimized.

The Noop I/O scheduler implements a simple first-in first-out (FIFO) scheduling algorithm. Merging of requests happens at the generic block layer, but is a simple last-hit cache. If a system is CPU-bound and the storage is fast, this can be the best I/O scheduler to use.


some notes about NFS

hi. here r some tips which i collected for my daily use of NFS. hopes helpful … 😉 .

some usefull commands :
# nfsstat -m     -Print information about each of the mounted NFS file systems. (install it with : apt-get install nfs-common)
# nfsstat -c        – A high number of NFS retransmissions can be detected
# nfsstat -r        – to see the current nfst statistics for retranmission of packets
# netstat -s       – Display summary statistics for each protocol.
# netstat -i        – To get the current value of your MTU
# showmount    – show mount information for an NFS server

Manually mounting with the mount command
# mount -t nfs -o hard,intr,rw,rsize=131072,wsize=131072   <nfs-ip-server>:/volume/<path>  /<my-path-to-mount>

or add following command in /etc/fstab to mount :
<nfs-ip-server>:/volume/<path>       /<my-path-to-mount>           nfs              hard,intr,rw,rsize=131072,wsize=131072   0 0

((( Common NFS Mount Options )))

  1. rsize=num and wsize=num — These settings speed up NFS communication for reads (rsize) and writes (wsize) by setting a larger data block size, in bytes, to be transferred at one time. Be careful when changing these values; some older Linux kernels and network cards do not work well with larger block sizes. For NFSv2 or NFSv3, the default values for both parameters is set to 8192. For NFSv4, the default values for both parameters is set to 32768.
  2. intr — Allows NFS requests to be interrupted if the server goes down or cannot be reached.
  3. hard or soft — Specifies whether the program using a file via an NFS connection should stop and wait (hard) for the server to come back online, if the host serving the exported file system is unavailable, or if it should report an error (soft).  If hard is specified, the user cannot terminate the process waiting for the NFS communication to resume unless the intr option is also specified.    If soft is specified, the user can set an additional timeo=<value> option, where <value> specifies the number of seconds to pass before the error is reported. Note:Using soft mounts is not recommended as they can generate I/O errors in very congested networks or when using a very busy server.
  4. nfsvers=2 or nfsvers=3 — Specifies which version of the NFS protocol to use. This is useful for hosts that run multiple NFS servers. If no version is specified, NFS uses the highest supported version by the kernel and mount command. This option is not supported with NFSv4 and should not be used.
  5. tcp — Specifies for the NFS mount to use the TCP protocol.
  6. udp — Specifies for the NFS mount to use the UDP protocol.

so which one to use:  It is strongly recommended to use NFS over TCP where possible, since TCP does not perform fragmentation. because Using NFS over UDP on high-speed links such as Gigabit can cause silent data corruption (refer to nfs manual page).

راهنمای گیت

gitگیت (به انگلیسی: Git) یک نرم‌افزار آزاد و متن‌باز برای مدیریت کد منبع توزیع شده است که هدف اصلی آن سرعت است. گیت ابتدا برای توسعه‌ی لینوکس توسط لینوس تروالدز به وجود آمد. هر مخزن گیت دارای تاریخچه‌ی کامل تغییرات است و برای کار با آن نیازی به دسترسی به شبکه یا سرور مرکزی وجود ندارد.

تاریخچه Git :

تا قبل از ۲۰۰۲ برای گسترش کرنل از هیچ نرم‌افزار کنترل نسخه استفاده نمی‌شد و هر فردی که در گسترش کرنل نقش داشت به شکل خصوصی از نرم‌افزار‌هایی مانتد SVN/CVS استفاده می‌کرد و دلیلش آن بود که هیچ کدام از نرم‌افزارهای کنترل نسخه این توانایی نداشتند که حجم تغییراتی که در لینوکس اتفاق می‌افتاد را پشتیبانی کنند. در این سال لینوس از BitKeeper به عنوان نرم‌افزار کنترل نسخه رسمی لینوکس استفاده کرد که به گسترش دهنده‌های کرنل (هر پروژه‌ی متن باز) اجازه می‌داد به صورت رایگان از BitKeeper استفاده کنند.

در سال ۲۰۰۵ اجازه‌ی استفاده رایگان از Bitkeeper برای گسترش دهندگان لینوکس محدود شد (به دلیل انجام مهندسی معکوس روی Bitkeeper) و لینوس شروع به جست‌و‌جو برای یافتن جایگزینی مناسب کرد. اما نرم‌افزار‌ها مناسبی پیدا نکرد که بتواند حجم تغییرات لینوکس را مدیریت کنند و این کمبود سبب شد تا لینوس به فکر نوشتن یک نرم‌افزار کنترل نسخه بیفتد. توسعه گیت در ماه آوریل سال ۲۰۰۵ اغاز شد و تنها ۲ هفته بعد از شروع توسعه، گیت قادر بود شاخه‌ها (branch) را ادغام (merge) کند. ۲ ماه بعد گیت به عنوان نرم‌افزار کنترل نسخه رسمی برای گسترش لینوکس مورد استفاده قرار گرفت.

ساختار گیت

در پوشه‌ی پایه‌ی هر پروژه که با استفاده از گیت مدیریت می‌شود پوشه‌ای با نام git. (نقطه git) وجود دارد که تمامی اطلاعات مربوط به پروژه (تاریخچه، برچسب‌ها، …) را در خود نگه می‌دارد. این ساختار بر خلاف ساختار subversion است که در هر زیرشاخه یک پوشه‌ی svn. (نقطه svn) دارد. از جمله پرونده‌هایی که در پوشه‌ی git. وجود دارند، config است که تنظیمات مخزن را در خود نگه می‌دارد.

فرامین گیت :

$ git init

با استفاده از این فرمان پوشه مخفی با نام git. در شاخه موجود ایجاد می گردد. این پوشه عملا استکلتی از مخزن پروژه می باشد. ولی در این مرحله هیچگونه فایلی از پروژه به مخزن اضافه نمی گردد.

 $ git add [files]

با استفاده از این فرمان فایل های مورد نظر به مخزن محلی اضافه می گردد . مانند :

$ git add *.c

$ git add README

 $ git commit

با استفاده از این فرمان تغییرات جدید (بر روی فایل هایی که با فرمان git add به مخزن اضافه گردیده اند) به مخزن محلی افزوده شده و ذخیره می گرددند. مانند :

$ git commit -m ‘initial project version

 دریافت مخزن از مخازن موجود :

برای دریافت مخازن جدید از مخازن موجود از این فرمان استفاده می گردد.

$ git clone

برای مثال فرمان زیر مخزن جدید از سایت github دریافت و ذخیری می نماید:

 $ git clone git://

این فرمان پوشه ای با نام grit ایجاد نموده و در آن فایل های سرور را کپی نموده و در انتها فایل ها را به مخزن محلی اضافه می نماید. برای تغییر نام شاخه ذخیر شده می توان از دستور زیر استفاده نمود :

 $ git clone git:// mygrit

همانطور که در فرامین بالا دیده می شود نرم افزار گیت از پروتکل git به جهت انتقال اطلاعات استفاده نموده است. این در صورتی است که می توان از پروتکل های ssh, http, ftp و … استفاده نمود. لازم به ذکر است که فرمت user@server:/path.git از پروتکل ssh استفاده می نماید.

 $ git status

این فرمان وضعیت تمامی فایل های موجود در مخزن را نشان می دهد. برای مثال :

$ git status

# On branch master

nothing to commit (working directory clean)

در مثال بالا مخزن بدون هیچگونه تغییر ذخیره نشده ای (اصطلاحا به این وضعیت clean میگویند) میباشد. معمولا وضعیت هایی مانند تغییر در فایل ها٬ حذف فایل٬ افزودن فایل و شاخه ای جدید نیاز به ذخیره سازی (commit) دارند.

 $ git log

این فرمان گزارشی از تغییرات ذخیره شده ( منظور اینجا commit ها میباشد) را نشان می دهد.

$ git log

commit ca82a6dff817ec66f44342007202690a93763949

Author: iman darabi <>

Date: Mon Mar 17 21:52:11 2013 -0700

changed the version number

 commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7

Author: Iman Darabi <>

Date: Sat Mar 15 16:40:33 2008 -0700

$ git commit –amend

در بسیاری از موارد بر اساس اشتباه یا … بازگشت به حالت قبل و حذف تغییرات ایجاد شده ( undo ) نیاز میشود. در نرم افزار گیت در بسیاری از موارد میتوان اینکار را انجام داد ولی بعضی از موارد این فرایند ممکن نخواهد بود.

یکی از موارد بازگشت به قبل ( undo ) بعد از commit زدن به پروژه است٬ بدین صورت که ممکن است بخواهیم قبل از commit زدن فایلی به پروژه اضافه کنیم ویا اینکه تغییراتی در فایل بدهیم. بدین منظور مانند مثال زیر عمل میکنیم :

$ git commit -m ‘initial commit’

$ git add forgotten_file

$ git commit –amend

$ git checkout

در صورتی که بخواهیم تغییرات اعمال شده به فایلی را حذف نماییم و آنرا به حالت قبل بازگردانیم از این دستور استفاده می نماییم. بازگشت به حالت قبلی میتواند به آخرین commit اعمال شده ویا حتی بازگشت به زمان اینجاد مخزن محلی صورت پذیرد . بدین منظور ابتدا با استفاده از فرمان git status وضعیت فعلی را بررسی مینماییم :

$git status

# Changed but not updated:

# (use “git add <file>…” to update what will be committed)

# (use “git checkout — <file>…” to discard changes in working directory)


# modified: benchmarks.rb


خروجی این فرمان نشان می دهد که فایل benchmarks.rb تغییر یافته است٬ بنابراین جهت حذف تغییرات بر روی این فایل بدین صورت استفاده می نماییم :

$ git checkout — benchmarks.rb

$ git status

# On branch master

# Changes to be committed:

# (use “git reset HEAD <file>…” to unstage)


# modified: README.txt


باید توجه داشت که این فرمان بسیار خطر ناک است٬ بعد از اجرای فرمان تغییرات بر روی فایل benchmarks.rb حذف شده و قابل بازگشت نمیباشد.

$ git remote

این فرمان مخزن اولیه ـ ای که پروژه از آن دریافت شده است ـ را نشان میدهد.

$ git remote


برای دیدن آدرس url مبدا باید از پارامتر v- استفاده نمود:

$ git remote -v

origin git://

$ git fetch [remote-name]

این فرمان تمامی تغییراتی را که بر روی سرور اعمال گردیده و بعد از آخرین دریافت اطلاعات از سرور بر روی مخزن محلی اعمال نشده است را دریافت نموده و ذخیره می نماید .

باید توجه داشت که این فرمان با اینکه آخرین تغییرات را از روی سرور بر روی مخازن محلی ذخیر میکند ولیکن تغییرات اعمال شده قبلی بر روی مخزن محلی را با تغییرات جدید بر روی سرور ادغام ( merge ) نمی نماید٬ و ادغام بایستی بصورت دستی صورت پذیرد.

$git push [remote-name] [branch-name]

در صورتیکه بخواهیم تغییرات و کدهای جدیدی که به مخزن محلی اضافه کرده ایم به سرور نیز اعمال گردد از فرمان git push استفاده می نماییم . برای مثال اگر بخواهیم تغییرات شاخه اصلی(master branch ) مخزن محلی را بر روی سرور اصلی(origin server ) اعمال نماییم از فرمان زیر استفاده می نماییم :

$ git push origin master

howto configure git server for daily local use ?

first :Image

# apt-get install git

to add user on git server :
$ adduser newUser
$ su git
$ cd
$ mkdir .ssh

change newUser shell from /bin/bash to /usr/bin/git-shell in /etc/passwd file.
if you want to use passless acccess so  add public key of users in /home/newUser/.ssh/authorized_keys like this :

$ cat /tmp/id_rsa.newUser >> ~/.ssh/authorized_keys

create empty project on server in newUser home directory :
$ cd
$ mkdir project.git
$ cd project.git
$ git –bare init

now you can push new project to server from local computer. to create a fresh new project :
$ cd myproject
$ git init
$ git add .
$ git commit -m ‘initial commit’
$ git remote add origin git@gitserver:/opt/git/project.git
$ git push origin master

to clone project from server, change project then push back to remote server:
$ git clone newUser@gitserver:project.git
$ vim README (change some file)
$ git commit -am ‘fix for the README file’
$ git push origin master