Regex special literal in C#

. : đại diện cho 1 ký tự bất kỳ trừ ký tự xuống dòng \n.
\d : ký tự chữ số tương đương [0-9]
\D : ký tự ko phải chữ số
\s : ký tự khoảng trắng tương đương [ \f\n\r\t\v]
\S : ký tự không phải khoảng trắng tương đương [ ^\f\n\r\t\v]
\w : ký tự word (gồm chữ cái và chữ số, dấu gạch dưới _ ) tương đương [a-zA-Z_0-9]
\W : ký tự không phải ký tự word tương đương [^a-zA-Z_0-9]
^ : bắt đầu 1 chuỗi hay 1 dòng
$ : kết thúc 1 chuỗi hay 1 dòng
\A : bắt đầu 1 chuỗi
\z : kết thúc 1 chuỗi
| : ký tự ngăn cách so trùng tương đương với phép or (lưu ý cái này nếu muốn kết hợp nhiều điều kiện)
[abc] : khớp với 1 ký tự nằm trong nhóm là a hay b hay c.
[a-z] so trùng với 1 ký tự nằm trong phạm vi a-z, dùng dấu - làm dấu ngăn cách.
[^abc] sẽ không so trùng với 1 ký tự nằm trong nhóm, ví dụ không so trùng với a hay b hay c.
() : Xác định 1 group (biểu thức con) xem như nó là một yếu tố đơn lẻ trong pattern .ví dụ ((a(b))c) sẽ khớp với b, ab, abc.
? : khớp với đứng trước từ 0 hay 1 lần. Ví dụ A?B sẽ khớp với B hay AB.
* : khớp với đứng trước từ 0 lần trở lên . A*B khớp với B, AB, AAB
+ : khớp với đứng trước từ 1 lần trở lên. A+B khớp với AB, AAB.
{n} : n là con số, Khớp đúng với n ký tự đúng trước nó . Ví dụ A{2}) khớp đúng với 2 chữ A.
{n, } : khớp đúng với n ký tự trở lên đứng trước nó , A{2,} khớp vói AA, AAA ...
{m,n} : khớp đùng với từ m->n ký tự đứng trước nó, A{2,4} khớp vói AA,AAA,AAAA

Heap, Stack and CLR (st)

MEMORY MANAGEMENT: VALUE v/s REFERENCE TYPES

• OS and runtimes often divide the memory used for holding the data into two separate chunks, each of which is managed in a distinct manner
• The two chunks of memory are traditionally called stack and heap
• The Stack and Heap serve different purposes:
o When a method is called, the memory required for its parameters and its local variables is always acquired from the stack
o When the method finishes (return value/throw exception), the memory acquired for the parameters and local variables is automatically released back to the stack and is available for reuse when another method is called
o When an object is created using the new keyword and a constructor call, the memory required to build the object is always acquired from the heap
o Same object can be referenced from several places by using reference variables. When the last reference to an object disappears, the memory used by the object disappears, the memory used by the object becomes available for reuse

CONECEPTS OF STACK AND HEAP
• Stack memory is organized like a stack of boxes piled on top of each other
• When a method is called, each parameter is put in a box, which is placed on top of the stack
• Each local variable likewise is assigned a box, and these are placed on top of the boxes already on the stack
• When a method finishes, all its boxes are removed from the stack
• Heap memory is like a large pile of boxes strewn around a room rather than stacked neatly on top of each other
• Each box has a label indicating whether it is in use or not
• When a new object is created, the runtime searches for an empty box and allocates it to the object
• The reference to the object is is stored in a local variable on the stack.
• The runtime keeps a track of the number of references to each box (important to remember that two variables can refer to the same object)
• When the last reference disappears, the runtime marks the box as not in use, and at some point in the future will empty the box and make it available for reuse
• IMPORTANT: Although the object itself is stored on the heap, the reference to the object is stored on the stack
• Heap memory is NOT infinite. If heap memory is exhausted, the new operator will throw OutOfMemoryException and the object will not be created

Comparison and cooperate HAProxy and Varnish

Common points between HAProxy and Varnish

Before comparing the differences, we can summarize the points in common:

·         reverse-proxy mode

·         advanced HTTP features

·         no SSL offloading

·         client-side HTTP 1.1 with keepalive

·         tunnel mode available

·         high performance

·         basic load-balancing

·         server health checking

·         IPv6 ready

·         Management socket (CLI)

·         Professional services and training available

Features available in HAProxy and not in Varnish

·         advanced load-balancer

·         multiple persistence methods

·         DOS and DDOS mitigation

·         Advanced and custom logging

·         Web interface

·         Server / application protection through queue management, slow start, etc…

·         SNI content switching

·         Named ACLs

·         Full HTTP 1.1 support on server side, but keep-alive

·         Can work at TCP level with any L7 protocol

·         Proxy protocol for both client and server

·         powerful log analyzer tool (halog)

·         <private joke> 2002 website design </private joke>

Features available in Varnish and not in HAProxy

·         caching

·         grace mode (stale content delivery)

·         saint mode (manages origin server errors)

·         modular software (with a lot of modules available)

·         intuitive VCL configuration language

·         HTTP 1.1 on server side

·         TCP connection re-use

·         Edge side includes (ESI)

·         a few command line tools for stats (varnishstat, varnishhist, etc…)

·         powerful live traffic analyzer (varnishlog)

·         <private joke> 2012 website design </private joke>

Conclusion

Mặc dù HAProxy có thể thực hiện TCP proxying, nhung nó thường được sử dụng phía trước web application, một cách chính xác những gì mà ta có thể tìm thấy ở Varnish.

Chúng hoàn toàn hợp tác với nhau rất tốt: Varnish sẽ làm cho web nhanh hơn bằng cách offloading các static object, trong khi HAProxy đảm bảo việc load-balancing smooth với smart persistence và khả năng giảm DDOS.

Cơ bản, HAProxy và Varnish là bạn với nhau, ngoại trừ một vài đặc tính đối chọi nhau :) Mỗi thứ đều là chuyên gia của mình trên miền riêng của mình: HAProxy is a reverse-proxy Load-Balancer and Varnish is a Reverse-proxy cache.

Why a single domain?

Trong ứng dụng web có 2 loại dữ liệu: static và dynamic.

Dynamic có nghĩa là nội dung được tạo theo yêu cầu request của từng user riêng biệt trên browsing hiện tại trên ứng dụng. Bất cứ thứ gì không nằm trong loại này thì được xem như là static. Mặc dù một trang được tạo ra từ PHP và nội dung của nó thay đổi mỗi phút hay vài giây (như CMS Wordpress hay drupal). Ta gọi những trang đó là “pseudo-statid”.

Điểm mạnh nhất của Varnish là có thể cache static object, phân phát chúng thay mặt server, offloading hầu hết traffic từ server.

Một đối tượng được xác định bởi Host header và URL. Khi bạn có một domain name, một Host header cho tất cả các request: static, pseudo static hay dynamic.

Bạn không thể chia traffice thành: mọi thứ request phải đến một loại của thiết bị: LB, cache…

Một trong những cách để chia nội dung dynamic và static là sử dụng một domain cho mỗi loại đối tượng: dynamic.domain.com cho dynamic và static.domain.com cho static. Thực hiện như vậy bạn có thể chuyển traffic dynamic đến LB và traffic static đến cache một cách trực tiếp.

Available Architecture

1.      CLIENT ==> HAPROXY ==> VARNISH ==> APPSERVER

2.      CLIENT ==> VARNISH ==> HAPROXY ==> APPSERVER

Pro and cons of HAProxy in front of Varnish

PROS:

·         Use HAProxy‘s smart load-balancing algorithm such as uri, url_param to makevarnish caching more efficient and improve the hit rate

·         Make the Varnish layer scalable, since load-balanced

·         Protect Varnish ramp up when starting up (related to thread pool creation)

·         HAProxy can protect against DDOS and slowloris

·         Varnish can be used as a WAF (web application firewall)

CONS:

·         no easy way do do application layer persistence

·         HAProxy queueing system can hardly protect the application hidden by Varnish

·         The client IP will be mandatory forwwarded on the X-Forwarded-For header (or any header you want)

Pro and cons of Varnish in front of HAProxy

PROS:

·         Smart layer 7 persistence with HAProxy

·         HAProxy layer scalable (with persistence preserved) since load-balanced by Varnish

·         APPSERVER protection through HAProxy request queueing

·         Varnish can be used as a WAF

·         HAProxy can use the client IP address (provided by Varnish in a HTTP header) to doTransparent proxying (getting connected on APPSERVER with the client ip)

CONS:

·         HAProxy can’t protect against DDOS, Varnish will do

·         Cache size must be big enough to store all objects

·         Varnish layer not scalable

Vậy đâu là kiến trúc tốt nhất?

Không cần phải chọn lựa kiến trúc nào kém hơn! Sẽ tốt hơn nếu quan tâm việc xây dựng platform mà không có điểm yếu.

Hình sau là mô hình chúng ta sẽ thực hiện:

Ghi chú:

·         H: HAProxy Load-Balancers

·         V: Varnish servers

·         S: Web application servers

·         C: Client or end user

Vai trò chính của mỗi layer:

·         HAProxy: Layer 7 traffic routing, first row of protection against DDOS (syn flood, slowloris, etc…), application request flow optimiation

·         Varnish: Caching, compression. Could be used later as a WAF to protect the application

·         Server: hosts the application and the static content

·         Client: browse and use the web application

Traffic Flow

Cơ bản, client sẽ gửi tất cả request đến HAProxy, sau đó HAProxy dựa trên URL hay file extension sẽ quyết định routing:

·         Nếu request giống như cho (pseudo) static object, thì forward nó đến Varnish. Nếu Varnish miss (bỏ qua) object, nó sẽ sử dụng HAProxy để lấy nội dung từ server.

·         Gửi tất các request khác đến appserver. Nếu bạn thực hiện một cách đúng đắn thì ở đây chỉ duy nhất có dynamic traffic.

Ta không sử dụng Varnish như tùy chọn mặc định trong flow này, vì nội dung dynamic có thể bị cache lại, dẫn đến thông tin cá nhân của một ai đó có thể bị leak cho mọi người. Hơn thế nữa, trong trường hợp “massive misses” hoặc các request được xây dựng để bypass cache, I don’t the servers to be hammered by Varnish, so HAProxy protects them with a tight traffic regulation between Varnish and appservers.

Dynammic traffic flow

Hình bên dưới chỉ ra request yêu cầu nội dung dynamic được route qua platform một cách lí tưởng:

Ghi chú:

1.       The client sends its request to HAProxy

2.       HAProxy chooses a server based on cookie persistence or Load-Balancing Algorithm if there is no cookie.
The server processes the request and send the response back to HAPRoxy which forwards it to the client

Static traffic flow

Hình bên dưới chỉ ra request yêu cầu nội dung static được route qua platform một cách lí tưởng

1.       The client sends its request to HAProxy which sees it asks for a static content

2.       HAProxy forward the request to Varnish. If Varnish has the object in Cache (a HIT), it forwards it directly to HAProxy.

3.       If Varnish doesn’t have the object in cache or if the cache has expired, then Varnish forwards the request to HAProxy

4.       HAProxy randomly chooses a server. The response goes back to the client through Varnish.

Trong trường hợp bị miss , luồng xử lí có tỏ ra nặng nề. Ta muốn làm chuyện đó với cách sử dụng các feature qui định của HAProxy để ngăn ngừa Varnish flood server. Hơn thế, vì Varnish chỉ nhìn thấy nội dung static, HIT rate của nó hơn 98% … Do đó overhead thì rất chậm và sự bảo vệ được cải thiện.

Pros of such architecture

·         Use smart load-balancing algorithm such as uri, url_param to make varnish caching more efficient and improve the hit rate

·         Make the Varnish layer scalable, since load-balanced

·         Startup protection for Varnish and APPSERVER, allowing server reboot or farm expansion even under heavy load

·         HAProxy can protect against DDOS and slowloris

·         Smart layer 7 persistence with HAProxy

·         APPSERVER protection through HAProxy request queueing

·         HAProxy can use the client IP address to do Transparent proxying (getting connected on APPSERVER with the client ip)

·         Cache farm failure detection and routing to application servers (worst case management)

·         Can load-balance any type of TCP based protocol hosted on APPSERVER

Cons of such architecture

To be totally fair, there are a few “non-blocking” issues:

·         HAProxy layer is hardly scalable (must use 2 crossed Virtual IPs declared in the DNS)

·         Varnish can’t be used as a WAF since it will see only static traffic passing through. This can be updated very easily

 Configuration

HAProxy configuration - http://pastebin.com/CYFN7kxE

Varnish configuration - http://pastebin.com/GqUWwtc2

Compile GCC 4.6.3

Let’s compiling your gcc, it’s so fun. Following is the very basic  instructions for newbie. If you want to compile with more option, you can go to homepage gcc.gnu.org/install/ for details.

Go to and find which pakage needed ftp.gnu.org/gnu

1. build & install gmp:

tar jxf gmp-4.3.2.tar.bz2 &&cd gmp-4.3.2/

./configure --prefix=/usr/local/gmp

make && make install

cd ..

2. build & install mpfr:

tar jxf mpfr-2.4.2.tar.bz2 ;cd mpfr-2.4.2/

./configure --prefix=/usr/local/mpfr --with-gmp=/usr/local/gmp

make && make install

cd ..

3. build & install mpc:

tar xzf mpc-0.8.1.tar.gz ;cd mpc-0.8.1

./configure --prefix=/usr/local/mpc --with-mpfr=/usr/local/mpfr --with-gmp=/usr/local/gmp

make && make install

cd ..

4. build & install gcc4.6.3

tar jxf gcc-4.6.3.tar.bz2 ;cd gcc-4.6.3

./configure --prefix=/usr/local/gcc --enable-threads=posix --disable-checking --disable-multilib --enable-languages=c,c++ --with-gmp=/usr/local/gmp -w-ith-mpfr=/usr/local/mpfr/ --with-mpc=/usr/local/mpc/

if [ $? -eq 0 ];then

echo "this gcc configure is success"

else

echo "this gcc configure is failed"

fi

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/mpc/lib:/usr/local/gmp/lib:/usr/local/mpfr/lib/

make && make install

[ $? -eq 0 ] && echo install success

5. set up the gcc env:

--> this is really important.

cp gcc.4.6.3.conf /etc/ld.so.conf.d/gcc.4.6.3.conf

ldconfig

mv /usr/bin/gcc /usr/bin/gcc_old

mv /usr/bin/g++ /usr/bin/g++_old

mv /usr/bin/c++ /usr/bin/c++_old

ln -s -f /usr/local/gcc/bin/gcc /usr/bin/gcc

ln -s -f /usr/local/gcc/bin/g++ /usr/bin/g++

ln -s -f /usr/local/gcc/bin/c++ /usr/bin/c++

cp /usr/local/gcc/lib64/libstdc++.so.6.0.16 /usr/lib64/.

mv /usr/lib64/libstdc++.so.6 /usr/lib64/libstdc++.so.6.bak

ln -s -f /usr/lib64/libstdc++.so.6.0.16 /usr/lib64/libstdc++.so.6

6. finished.

you could run gcc --version to check if the current gcc version is gcc4.6.3, and also need to check g++, to see if the version is changed to g++4.6.3 too.

Linux Booting Process

Booting process bắt đầu từ BIOS, BIOS sẽ nói cho computer biết là ổ cứng nào available và cố tìm ra active MBR record trên primary hard drive. Sau đó, MBR record chỉ cho booting process biết vị trí /boot partition để thực hiện đọc và kiểm tra khi thực hiện boot loader (trong trường hợp này là GRUB)

Bây giờ việc booting của computer được giao cho GRUB boot loader, nó sẽ load grub.conf file và kernel của hệ thống Linux, sau đó mount root partition (trong trường hợp này là /dev/sda3). Việc thực thi tiếp tục với kernel image nằm trong /boot partition. Kernel được load lên, và thực thi được chuyển cho Gentoo init process (với PID là 1) đã nằm trong partition hệ thống và chịu trách nhiệm cho việc khởi động toàn bộ hệ thống.

Init process sẽ thực hiện sẽ lo mọi thứ để hệ thống có thể boot thành công. Một trong những việc được thực hiện khi khởi động là chạy các script startup (thường trong thư mục /etc/rc.d/), cũng như việc mount các partition được liệt kê trong file /etc/fstab. Một khi mọi thưc được hoàn thành, login window xuất hiện, cho phép chúng ta login vào hệ thống.

BIOS và MBR

 Một trong những thành phần quan trọng của máy tính là BIOS, bắt đầu cho việc booting process ngay sau khi bấm nút turn on máy tính. Nhưng tại sao chúng ta lại cần BIOS? Lí do là vì boot loader nằm trong hard drive, ngay sau khi mở máy, processor không biết bất kì thông tin gì về boot loader nằm trên hard drive. Công việc của BIOS là tìm và load boot loader đã được cài.

Cụ thể hơn, ngay sau khi mở máy, BIOS sẽ thực hiện scan tất cả các thiết bị, xác định memory available,… Sau đó, BIOS scan bootable device được config trong BIOS setting, BIOS tìm thấy hard drive chứa MBR (Master Boot Record), đây cũng là nới chứa primary boot loader code.

Ngay khi tìm thấy MBR record, nó chuyển quyền điều khiển với primary boot loader. Boot loader scan toàn bộ bảng partition được ghi trong MBR record và tìm kiểm active partition, nơi chứa sencondary boot loader.

Let’s dump and explore:

dd if=/dev/sda of=/tmp/mbr.bin bs=512 count=1
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.0358849 s, 14.3 kB/s

Xem thông tin của file mbr:

# file mbr.bin | tr ';' '\n'
mbr.bin: x86 boot sector
 partition 1: ID=0x83, active, starthead 32, startsector 2048, 40103936 sectors
 partition 2: ID=0x5, starthead 254, startsector 40108030, 1832962 sectors, code offset 0x63

Chúng ta có thể thấy được 446 byte đầu dành cho boot loader. Có 4 partion entry, cho chúng ta thấy được tại sao chỉ có thể set up 4 primary partition, nếu muốn thêm chúng ta phải sử dụng logical partition. MBR kết thúc với singature 0x55a.

# xxd /tmp/mbr.bin | sed 's/  .*//g'
0000000: eb63 9010 8ed0 bc00 b0b8 0000 8ed8 8ec0
0000010: fbbe 007c bf00 06b9 0002 f3a4 ea21 0600
0000020: 00be be07 3804 750b 83c6 1081 fefe 0775
0000030: f3eb 16b4 02b0 01bb 007c b280 8a74 018b
0000040: 4c02 cd13 ea00 7c00 00eb fe00 0000 0000
0000050: 0000 0000 0000 0000 0000 0080 0100 0000
0000060: 0000 0000 fffa 9090 f6c2 8075 02b2 80ea
0000070: 747c 0000 31c0 8ed8 8ed0 bc00 20fb a064
0000080: 7c3c ff74 0288 c252 bb17 0480 2703 7406
0000090: be88 7de8 1c01 be05 7cf6 c280 7448 b441
00000a0: bbaa 55cd 135a 5272 3d81 fb55 aa75 3783
00000b0: e101 7432 31c0 8944 0440 8844 ff89 4402
00000c0: c704 1000 668b 1e5c 7c66 895c 0866 8b1e
00000d0: 607c 6689 5c0c c744 0600 70b4 42cd 1372
00000e0: 05bb 0070 eb76 b408 cd13 730d f6c2 800f
00000f0: 84d0 00be 937d e982 0066 0fb6 c688 64ff
0000100: 4066 8944 040f b6d1 c1e2 0288 e888 f440
0000110: 8944 080f b6c2 c0e8 0266 8904 66a1 607c
0000120: 6609 c075 4e66 a15c 7c66 31d2 66f7 3488
0000130: d131 d266 f774 043b 4408 7d37 fec1 88c5
0000140: 30c0 c1e8 0208 c188 d05a 88c6 bb00 708e
0000150: c331 dbb8 0102 cd13 721e 8cc3 601e b900
0000160: 018e db31 f6bf 0080 8ec6 fcf3 a51f 61ff
0000170: 265a 7cbe 8e7d eb03 be9d 7de8 3400 bea2
0000180: 7de8 2e00 cd18 ebfe 4752 5542 2000 4765
0000190: 6f6d 0048 6172 6420 4469 736b 0052 6561
00001a0: 6400 2045 7272 6f72 0d0a 00bb 0100 b40e
00001b0: cd10 ac3c 0075 f4c3 6f1f 0100 0000 8020
00001c0: 2100 83fe ffff 0008 0000 00f0 6302 00fe
00001d0: ffff 05fe ffff feff 6302 02f8 1b00 0000
00001e0: 0000 0000 0000 0000 0000 0000 0000 0000
00001f0: 0000 0000 0000 0000 0000 0000 0000 55aa

Secondary boot loader có thể là GRUB hay LILO và Bootmgr cho Window. Công việc của nó là load kernel và boot OS. Primary boot loader tìm active partition và load VBR (Volume Boot Record) vào bộ nhớ. VBR là boot sector có chứa machine code cho các chương trình bootstrapping, thường được hệ điều hành lưu trong các phần khác của device.

Thường có trường hợp install GRUB hoặc LILO boot loader trực tiếp vào MBR, vì nếu chúng ta không làm vậy, BIOS vẫn cần primary bootloader sau đó load secondary one. Nhưng tại sao chúng ta không thể cài GRUB trực tiếp vào MBR như primary boot loader. Đây là thực sự cách mặc định mà GRUB/LILO được cài đặt hiện nay.

Để install GRUB như primary boot loader, ta sẽ install nó trên MBR như sau:

# grub-install --no-floppy /dev/sda

Để install GRUB trên VBR của partition /dev/sda1

# grub-install --no-floppy /dev/sda1

Nhìn vào trong thư mục /boot/grub:

# ls /boot/grub/
default     e2fs_stage1_5  ffs_stage1_5  iso9660_stage1_5  menu.lst        reiserfs_stage1_5  stage1  stage2.old       ufs2_stage1_5    xfs_stage1_5

device.map  fat_stage1_5   grub.conf     jfs_stage1_5      minix_stage1_5  splash.xpm.gz      stage2  stage2_eltorito  vstafs_stage1_5

ta có thể biết boot loader hỗ trợ những kiểu file system. GRUB supports the following file systems: ext2, DOS FAT16, FAT32, FFS, JFS, ReiserFS, MinixFS, UFS, XFS, VstaFS and Iso9660.

Document /proc/sys/fs/*

file-max & file-nr

The value in file-max denotes the maximum number of file-handles that the Linux kernel will allocate. When you get lots of error messages about running out of file handles, you might want to increase this limit. Historically,the kernel was able to allocate file handles dynamically, but not to free them again. The three values in file-nr denote the number of allocated file handles, the number of allocated but unused file handles, and the maximum number of file handles. Linux 2.6 always reports 0 as the number of free file handles -- this is not an error, it just means that the number of allocated file handles exactly matches the number of used file handles. Attempts to allocate more file descriptors than file-max are reported with printk, look for "VFS: file-max limit / reached".

nr_open (ulimit -n)

This denotes the maximum number of file-handles a process can allocate. Default value is 1024*1024 (1048576) which should be enough for most machines. Actual limit depends on RLIMIT_NOFILE resource limit.

inode-max, inode-nr & inode-state

As with file handles, the kernel allocates the inode structures dynamically, but can't free them yet. The value in inode-max denotes the maximum number of inode handlers. This value should be 3-4 times larger than the value in file-max, since stdin, stdout and network sockets also need an inode struct to handle them. When you regularly run out of inodes, you need to increase this value. The file inode-nr contains the first two items from inode-state, so we'll skip to that file... Inode-state contains three actual numbers and four dummies. The actual numbers are, in order of appearance, nr_inodes, nr_free_inodes and preshrink. Nr_inodes stands for the number of inodes the system has allocated, this can be slightly more than inode-max because Linux allocates them one pageful at a time. Nr_free_inodes represents the number of free inodes (?) and preshrink is nonzero when the nr_inodes > inode-max and the system needs to prune the inode list instead of allocating more.

overflowgid & overflowuid:

Some filesystems only support 16-bit UIDs and GIDs, although in Linux UIDs and GIDs are 32 bits. When one of these filesystems is mounted with writes enabled, any UID or GID that would exceed 65535 is translated to a fixed value before being written to disk. These sysctls allow you to change the value of the fixed UID and GID. The default is 65534.

suid_dumpable

This value can be used to query and set the core dump mode for setuid or otherwise protected/tainted binaries. The modes are 0 - (default) - traditional behaviour. Any process which has changed privilege levels or is execute only will not be dumped 1 - (debug) - all processes dump core when possible. The core dump is owned by the current user and no security is applied. This is intended for system debugging situations only. Ptrace is unchecked. 2 - (suidsafe) - any binary which normally would not be dumped is dumped readable by root only. This allows the end user to remove such a dump but not access it directly. For security reasons core dumps in this mode will not overwrite one another or other files. This mode is appropriate when administrators are attempting to debug problems in a normal environment.

super-max & super-nr

These numbers control the maximum number of superblocks, and thus the maximum number of mounted filesystems the kernel can have. You only need to increase super-max if you need to mount more filesystems than the current value in super-max allows you to.

aio-nr & aio-max-nr

aio-nr shows the current system-wide number of asynchronous io requests. aio-max-nr allows you to change the maximum value aio-nr can grow to.

/proc/sys/fs/mqueue - POSIX message queues filesystem

The "mqueue" filesystem provides the necessary kernel features to enable the creation of a user space library that implements the POSIX message queues API (as noted by the MSG tag in the POSIX 1003.1-2001 version of the System Interfaces specification.) The "mqueue" filesystem contains values for determining/setting the amount of resources used by the file system. /proc/sys/fs/mqueue/queues_max is a read/write file for setting/getting the maximum number of message queues allowed on the system. /proc/sys/fs/mqueue/msg_max is a read/write file for setting/getting the maximum number of messages in a queue value. In fact it is the limiting value for another (user) limit which is set in mq_open invocation. This attribute of a queue must be less or equal then msg_max. /proc/sys/fs/mqueue/msgsize_max is a read/write file for setting/getting the maximum message size value (it is every message queue's attribute set during its creation).

/proc/sys/fs/epoll/max_user_watches - Configuration options for the epoll interface

This directory contains configuration options for the epoll(7) interface. Every epoll file descriptor can store a number of files to be monitored for event readiness. Each one of these monitored files constitutes a "watch". This configuration option sets the maximum number of "watches" that are allowed for each user. Each "watch" costs roughly 90 bytes on a 32bit kernel, and roughly 160 bytes on a 64bit one. The current default value for max_user_watches is the 1/32 of the available low memory, divided for the "watch" cost in bytes.

UNIX Architecture

OS cũng như một phần mềm điều khiển hardware resource của máy tính và cung cấp môi trường cho các chương trình chạy.  Một cách tổng quát, người ta phần mềm đó là kernel, vì nó khá nhỏ và nằm trong môi trường lõi. 

Hình: Architecture of the UNIX operating system

Cổng giao tiếp (interface) với kernel ta phải dùng system call (đây cũng là một lớp phần mềm). Thư viện của các hàm chức năng được xây dựng dựa trên system call này, ứng dụng có khả năng tùy ý sử dụng một trong hai. Shell là một ứng dụng đặc biệt cung cấp một interface cho chạy ứng dụng khác.

Khái quát hơn, OS là kernel và tất cả các phần mềm làm cho máy tính có ích cho người dùng. Các phần mềm đó bao gồm system ulity, application, shell, librabry of common function...

HTTP transaction overview

Requests

Gõ địa chỉ URL như sau vào browser : http://hypothetical.ora.com:80/

Browser sẽ phân tích URL như sau:

http:// Sử dụng HTTP (Hypertext Transfer Protocol)

hypothetical.ora.com Hostname của server sẽ liên hệ

:80 Kết nối vào port 80. Port range từ 1-65535, mặc định nếu không ghi rõ :port theo sau thì browser sẽ sử dụng port 80

/ Đường dẫn thư mục

Do đó browser sẽ kết nối đến hypothetical.ora.com port 80 sử dụng giao thức HTTP. Request header sẽ như sau:

1.     GET / HTTP/1.1

2.     Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

3.     Accept-Language: en-us

4.     Accept-Encoding: gzip, deflate

5.     User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT)

6.     Host: hypothetical.ora.com

7.     Connection: Keep-Alive

Dòng 1: Sử dụng phương thức GET (còn nhiều phương thức khác nữa) để yêu cầu lấy document tại / , version của giao thức HTTP mà browser sử dụng.

Dòng 2: Loại tài liệu nào sẽ được browser chấp nhận.

Dòng 3: Chỉ ra ngôn ngữ sử dụng (ở đây là English). Có thể khai báo nhiều loại ngôn ngữ nếu trên server có cùng một loại tài liệu mà có nhiều ngôn ngữ khác nhau.

Dòng 4: Xác định thuật toán compress nào mà client có thể hiểu khi nhận response của server

Dòng 5: Thông tin về client, browser.

Dòng 6: nói với server rằng client ngĩ host name của server là như zậy. Header này bắt buộc trong HTTP 1.1, nhưng tùy chọn trong HTTP 1.0. Vì server có thể có nhiều hostname, client cần phải xác định hostname nào sẽ nhận được request. Trong trường hợp này web server có thể có nhiều cây tài liệu khác nhau cho mỗi hostname. Nếu client không xác định hostname thì server không thể xác định cây tài liệu nào sử dụng.

Dòng 7: nói với server giữ kết nối cho đến bảo ngắt kết nối thì thôi (đây là mặc định trong HTTP 1.1). Đối với HTTP 1.0 kết nối sẽ được đóng lại ngay sau khi client requeset.

Responses

Với request yêu cầu như trên, server sẽ tìm kiếm resource có liên quan đến “/” và trả nó về cho browser, resource liên quan đến URL phụ thuộc vào cách server được implemented. Đó có thể là file static hoặc dynamic. Ví dụ server trả về response như sau:

1.           HTTP/1.1 200 OK

2.           Date: Mon, 06 Dec 1999 20:54:26 GMT

3.           Server: Apache/1.3.6 (Unix)

4.           Last-Modified: Fri, 04 Oct 1996 14:06:11 GMT

5.           ETag: "2f5cd-964-381e1bd6"

6.           Accept-Ranges: bytes

7.           Content-length: 327

8.           Connection: close

9.           Content-type: text/html

10.          

11.         <title>Sample Homepage</title>

12.         <img src="/images/oreilly_mast.gif">

13.         <h1>Welcome</h1>

14.         Hi there, this is a simple web page.  Granted,

15.         it may not be as elegant as some other web

16.         pages you've seen on the net, but there are

17.         some common qualities:

18.          

19.         <ul>

20.         <li> An image,

21.         <li> Text,

22.         <li> and a <a href="/example2.html"> hyperlink. </a>

23.         </ul>

Từ dòng 1-9 là response header, phần còn lại là body (hay còn gọi là body of entity  hay entity-body)

Dòng 1: Giao thức HTTP mà server sử dụng. Theo sau là status code, ở đây là 200 cho biết tài liệu được tìm thấy và trả về cho client.

Dòng 2: Thời gian hiện tại của server, theo định dạng GMT

Dòng 3: Cho biết loại phần mêm nào server sử dụng, ở đây là Apache version 1.3.6 chạy trên Unix

Dòng 4: xác định thời gian chỉnh sửa gần nhất của tài liệu được request bởi client. Mục đích modification time là phục vụ cho việc caching, browser sẽ không cần request toàn bộ file đó nếu modification time của nó không thay đổi.

Dòng 5: xác định entity tag. Cái này cung cấp cho web client một số định danh duy nhất cho server resource. Rất khó cho 2 server resource khác nhau có cùng một entity tag. Đây là cơ chế mạnh mẽ cho việc caching.

Dòng 6: cho browser biết server có khả năng trả về một một phần (subsection) của tài liệu, thay vì trả về toàn bộ document mỗi khi được request. (This is useful for retrieving records in a document, which may be useful for database and streaming multimedia applications.) server cho biết khoảng chấp nhận request cho một resource (to indicate its acceptance of range request for a resource). Origin servers that accept byte-range request MAY send : Accept-Ranges: bytes

Dòng 7: cho client biết body kích thước bao nhiêu byte.

Dòng 8: xác định kết nối sẽ đóng sau khi server response. Nếu client muốn gửi một request khác thì nó phải mở một kết nối khác đến server.

Dòng 9: cho client biết loại tài liệu nào server trong response của nó. Ở đây là HTML.

Figure 1.1. A simple transaction

Structure of HTTP Transactions

Tổng quát hóa header của request và response, ta có 2 hình sau:

Figure 1.2. Structure of a client request

HTTP transaction không cần sử dụng hết tất cả các header. Có thể suy ra ta có thể thực hiện HTTP request mà không cần điền bất kì thông tin header nào cả. Ví dụ, trường hợp đơn giản nhất, request GET / HTTP/1.0 không cần bất kì header nào cũng đủ cho hầu hết các server hiểu được client.

HTTP requests thành phần tổng quát sau:

Dòng đâu tiên chỉ ra method mà client sử dụng, loại tài liệu (entity) được áp dụng lên, HTTP version mà client đang dùng. Method trong HTTP 1.1 có thể là GET, POST, HEAD, PUT, LINK, UNLINK, DELETE, OPTIONS, and TRACE. HTTP 1.0 không hỗ trợ OPTIONS và TRACE Không phải tất cả method đều được hỗ trợ bở server.

General message headers là optional headers được sử dụng cả trong client request và server response. Xác định những thông tin chung như thời gian hiện tại.

Request headers cho server biết thêm thông tin về client.

Entity headers được sử dụng khi một tài liệu (entity) được gửi đi. Nó chỉ ra những thông tin về entity như encoding scheme, length, type và origin.

Figure 1.3. Structure of a server response

Trong server response, general header và entity header giống với những gì được sử dụng trong client request. Entity-body giống trong client request, chỉ khác ở chỗ nó được sử dụng để response.

Dòng đầu tiên chỉ ra version HTTP mà server sử dụng. Server sẽ có gắng để phù hợp với version tương thích nhất của HTTP mà client đang dùng, status code chỉ ra kết quả của request, và reason-phrase là human-readable description của status code.