Threads vs. Processes

Both threads and processes are methods of parallelizing an application. However, processes are independent execution units that contain their own state information, use their own address spaces, and only interact with each other via interprocess communication mechanisms (generally managed by the operating system). Applications are typically divided into processes during the design phase, and a master process explicitly spawns sub-processes when it makes sense to logically separate significant application functionality. Processes, in other words, are an architectural construct.

By contrast, a thread is a coding construct that doesn't affect the architecture of an application. A single process might contains multiple threads; all threads within a process share the same state and same memory space, and can communicate with each other directly, because they share the same variables.

Threads typically are spawned for a short-term benefit that is usually visualized as a serial task, but which doesn't have to be performed in a linear manner (such as performing a complex mathematical computation using parallelism, or initializing a large matrix), and then are absorbed when no longer required. The scope of a thread is within a specific code module—which is why we can bolt-on threading without affecting the broader application.

Showing unlimted quota in WHM(VPS)!! or /scripts/fixauotas results 'No filesystems with quota detected '

This is neither a cPanel nor a Virtuozzo issue.

You should check whether your user/group quotas are enabled or not :

e.g.

vzquota stat 101 -t

resource usage softlimit hardlimit grace
1k-blocks 14929508 51200000 51200000
inodes 222034 400000 440000

User/group quota: off,inactive
Ugids: loaded 0, total 0, limit 0
Ugid limit was exceeded: no

Enable quotas over Virtuozzo. If there are hardware or other
problems who prevent this setting do it manually:

vi /etc/sysconfig/vz-scripts/101.conf

change QUOTAUGIDLIMIT="0" to QUOTAUGIDLIMIT="3000" (QUOTAUGIDLIMIT > This is used for tracking quote for all your files in the system)

restart VPS. Done.

Login to the VPS (VEID) and run /scripts/fixquotas

Problem should be solved.

Sylesh

ffmpeg in CentOS is with yum

The most easy way to install ffmpeg in CentOS is with yum.
First of all, edit /etc/yum.repos.d/CentOS-Base.repo and add those lines at bottm of file:
[dag]
name=Dag RPM Repository for Centos
baseurl=http://apt.sw.be/redhat/el$releasever/en/$basearch/dag
enabled=1

Then, run command:
yum install ffmpeg

Or, you can install from svn:

svn checkout svn://svn.mplayerhq.hu/ffmpeg/trunk ffmpeg

cd ffmpeg
./configure --help

add some parameters, like --enable-gpl, --enable-libmp3lame, etc..

make && make install

(if svn command not found, type yum install subversion)

Hope this help

traceroute

When you execute a trace route command (ie traceroute yahoo.com), your machine sends out 3 UDP packets with a TTL (Time-to-Live) of 1. When those packets reach the next hop router, it will decrease the TTL to 0 and thus reject the packet. It will send an ICMP Time-to-Live Exceeded (Type 11), TTL equal 0 during transit (Code 0) back to your machine - with a source address of itself, therefore you now know the address of the first router in the path.

Next your machine will send 3 UDP packets with a TTL of 2, thus the first router that you already know passes the packets on to the next router after reducing the TTL by 1 to 1. The next router decreases the TTL to 0, thus rejecting the packet and sending the same ICMP Time-to-Live Exceeded with its address as the source back to your machine. Thus you now know the first 2 routers in the path.

This keeps going until you reach the destination. Since you are sending UDP packets with the destination address of the host you are concerned with, once it gets to the destination the UDP packet is wanting to connect to the port that you have sent as the destination port, since it is an uncommon port, it will most like be rejected with an ICMP Destination Unreachable (Type 3), Port Unreachable (Code 3). This ICMP message is sent back to your machine, which will understand this as being the last hop, therefore trace route will exit, giving you the hops between you and the destination.

The UDP packet is sent on a high port, destined to another high port. On a Linux box, these ports were not the same, although usually in the 33000. The source port stayed the same throughout the session, however the destination port was increase by one for each packet sent out.

One note, traceroute actually sends 1 UDP packet of TTL, waits for the return ICMP message, sends the second UDP packet, waits, sends the third, waits, etc, etc, etc.

If during the session, you receive * * *, this could mean that that router in the path does not return ICMP messages, it returns messages with a TTL too small to reach your machine or a router with buggy software. After a * * * within the path, trace route will still increment the TTL by 1, thus still continuing on in the path determination.

The DNS Database Files

Master files included by named, like named.hosts, always have a domain associated with them, which is called the origin. This is the domain name specified with the cache and primary commands. Within a master file, you are allowed to specify domain and host names relative to this domain. A name given in a configuration file is considered absolute if it ends in a single dot, otherwise it is considered relative to the origin. The origin all by itself may be referred to using ``@''.

All data contained in a master file is split up in resource records, or RRs for short. They make up the smallest unit of information available through DNS. Each resource record has a type. A records, for instance, map a hostname to an IP-address, and a CNAME record associates an alias for a host with its official hostname.

Resource record representations in master files share a common format, which is

           [domain] [ttl] [class] type rdata

Fields are separated by spaces or tabs. An entry may be continued across several lines if an opening brace occurs before the first newline, and the last field is followed by a closing brace. Anything between a semicolon and a newline is ignored.

domain

This is the domain name to which the entry applies. If no domain name is given, the RR is assumed to apply to the domain of the previous RR.

ttl

In order to force resolvers to discard information after a certain time, each RR is associated a ``time to live'', or ttl for short. The ttl field specifies the time in seconds the information is valid after it has been retrieved from the server. It is a decimal number with at most eight digits. If no ttl value is given, it defaults to the value of the minimum field of the preceding SOA record.

class

This is an address class, like IN for IP addresses, or HS for objects in the Hesiod class. For TCP/IP networking, you have to make this IN. If no class field is given, the class of the preceding RR is assumed.

type

This describes the type of the RR. The most common types are A, SOA, PTR, and NS. The following sections describe the var- ious types of RR's.

rdata

This holds the data associated with the RR. The format of this field depends on the type of the RR. Below, it will be described for each RR separately.

The following is an incomplete list of RRs to be used in DNS master files. There are a couple more of them, which we will not explain. They are experimental, and of little use generally.

SOA

This describes a zone of authority (SOA means ``Start of Authority''). It signals that the records following the SOA RR contain authoritative information for the domain. Every master file included by a primary statement must contain an SOA record for this zone. The resource data contains the following fields:

origin

This is the canonical hostname of the primary name server for this domain. It is usually given as an absolute name.

contact

This is the email address of the person responsible for maintaining the domain, with the `@' character replaced by a dot. For instance, if the responsible person at the Virtual Brewery is janet, then this field would contain janet.vbrew.com.

serial

This is the version number of the zone file, expressed as a single decimal number. Whenever data is changed in the zone file, this number should be incremented. The serial number is used by secondary name servers to recognize when zone information has changed. To stay up to date, secondary servers request the primary server's SOA record at certain intervals, and compare the serial number to that of the cached SOA record. If the number has changed, the secondary servers transfers the whole zone database from the primary server.

refresh

This specifies the interval in seconds that the sec- ondary servers should wait between checking the SOA record of the primary server. Again, this is a deci- mal number with at most eight digits. Generally, the network topology doesn't change too often, so that this number should specify an interval of roughly a day for larger networks, and even more for smaller ones.

retry

This number determines the intervals at which a sec- ondary server should retry contacting the primary server if a request or a zone refresh fails. It must not be too low, or else a temporary failure of the server or a network problem may cause the secondary server to waste network resources. One hour, or perhaps one half hour, might be a good choice.

expire

This specifies the time in seconds after which the server should finally discard all zone data if it hasn't been able to contact the primary server. It should normally be very large. Craig Hunt ([ GETST "hunt-tcpip" ]) recommends 42 days.

minimum

This is the default ttl value for resource records that do not explicitly specify one. This requires other name servers to discard the RR after a certain amount of time. It has however nothing to do with the time after which a secondary server tries to update the zone information. minimum should be a large value, especially for LANs where the network topology almost never changes. A value of around a week or a month is probably a good choice. In the case that single RRs may change more frequently, you can still assign them different ttl's.

A

This associates an IP address with a hostname. The resource data field contains the address in dotted quad nota- tion. For each host, there must be only one A record. The hostname used in this A record is considered the official or canonical hostname. All other hostnames are aliases and must be mapped onto the canonical hostname using a CNAME record.

NS

This points to a master name server of a subordinate zone. For an explanation why one has to have NS records, see section 3.6. The resource data field contains the hostname of the name server. To resolve the hostname, an additional A record is needed, the so-called glue record which gives the name server's IP address.

CNAME

This associates an alias for a host with its canonical hostname. The canonical hostname is the one the master file provides an A record for; aliases are simply linked to that name by a CNAME record, but don't have any other records of their own.

PTR

This type of record is used to associate names in the in- addr.arpa domain with hostnames. This is used for reverse map- ping of IP addresses to hostnames. The hostname given must be the canonical hostname.

MX

This RR announces a mail exchanger for a domain. The rea- sons to have mail exchangers are discussed in section 14.4.1 in chapter 14.. The syntax of an MX record is

                     [domain] [ttl] [class] MX preference host

host names the mail exchanger for domain. Every mail exchanger has an integer preference associated with it. A mail transport agent who desires to deliver mail to domain will try all hosts who have an MX record for this domain until it succeeds. The one with the lowest preference value is tried first, then the others in order of increasing preference value.

HINFO

This record provides information on the system's hardware and software. Its syntax is

                     [domain] [ttl] [class] HINFO hardware software

The hardware field identifies the hardware used by this host. There are special conventions to specify this. A list of valid names is given in the ``Assigned Numbers'' (RFC 1340). If the field contains any blanks, it must be enclosed in double quotes. The software field names the operating sys- tem software used by the system. Again, a valid name from the ``Assigned Numbers'' RFC should be chosen.

Explaining DNS Database Files

Explaining DNS Database Files

This is a typical DNS zone.domain file for the domain maxx.net. (Its name would be zone.maxx.net. It will translate from a host name to its IP address.)

; ; Addresses for the local domain

maxx.net. IN SOA nova.maxx.net. tyager.nova.maxx.net. (

9602171 ; Serial 36000 ; Refresh every 10 hours 3600 ; Retry after 1 hour 360000 ; Expire after 100 hours 36000 ; Minimum TTL is 10 hours )

; Define name servers ; maxx.net. IN NS nova.maxx.net. maxx.net. IN A 204.251.17.241

; Define localhost ; localhost IN A 127.0.0.1

; Set up hosts ; maxx IN A 204.251.17.241 IN MX 5 nova.maxx.net.

maxx.net. IN MX 5 nova.maxx.net. ; ; All mail for net delivered to nova ; ;* IN MX 10 nova.maxx.net. www IN CNAME nova.maxx.net. ftp IN CNAME nova.maxx.net. news IN CNAME nova.maxx.net. mail IN CNAME nova.maxx.net. ns IN CNAME nova.maxx.net. loghost IN CNAME nova.maxx.net. lucy IN A 204.251.17.242 linux IN CNAME lucy.maxx.net. lucy IN MX 10 lucy.maxx.net. messdos IN A 204.251.17.243 messdos IN MX 10 messdos.maxx.net. pentium IN CNAME messdos.maxx.net. solaris IN A 204.251.17.244 solaris IN MX 10 solaris.maxx.net. maxx4 IN CNAME solaris.maxx.net. maxx5 IN A 204.251.17.245 maxx5 IN MX 10 maxx5.maxx.net. maxx6 IN A 204.251.17.246 maxx6 IN MX 10 maxx6.maxx.net.

Most database file entries are known as DNS resource records. Generally, the resource records are shown in order: SOA, NS, followed by the other types, but this ordering isn't required. The data in each entry may be entered in upper, lower, or mixed case. All entries in the database file must start at the beginning of the line. Blank lines as well as any text following a semicolon is ignored.

SOA stands for Start of Authority. This acronym notifies named that operational parameters follow. The most important one is the Serial field. Every time you make a change to a database file, you must increment its serial number. Only by doing this will secondary servers know they need to reach into your system and pull out new name server data, a procedure known as a "zone transfer." Many DNS administrators use a date-time stamp for this field, like 9602171 for the first version on February 17, 1996.

First, focus on the SOA section:

maxx.net. IN SOA nova.maxx.net. tyager.maxx.maxx.net.

The "maxx.net." field tells named the domain defined by this file. The name server will automatically append it to any host name that appears in the file. The trailing dot is not a type; it keeps named from trying to tack on your domain name. Without it, the resolver would be confused by named's expansion of my domain name to "maxx.net.maxx.net."

The IN stands for the "Internet" class of data. Even though other classes exist, they aren't in common usage. The "nova.maxx.net" field is the host on which these database files reside. Finally, "tyager.nova.maxx.net" represents the e-mail address of the DNS administrator, where the first dot (between tyager and nova) would be replaced by the @ symbol to create a valid address. (The @ symbol can't be used here because it has a reserved meaning in DNS database files.)The open parenthesis at the end of the line allows you to split the SOA record across physical lines for readability:

9602171 ; Serial

36000 ; Refresh every 10 hours 3600 ; Retry after 1 hour 360000 ; Expire after 100 hours 36000 ; Minimum TTL is 10 hours )

The "serial" field was discussed earlier.

The remaining four fields specify various time intervals (all values in seconds) used by the secondary name server:

Refresh

The time interval that must elapse between each poll of the primary by the secondary name server (here 36,000 seconds or 10 hours). If the "serial number" has been updated on the primary, the secondary assumes its data is stale and requests updated information as a "zone transfer."

Retry

The time interval used between successive connection attempts by the secondary to reach the primary name server in case the first attempt failed (here 3,600 seconds or one hour). Generally, less than the "refresh" time.

Expire

The time interval after which the secondary expires its data if it can't reach the primary name server (here 360,000 seconds or 100 hours). The secondary will refuse to service requests after this interval.

Minimum

The minimum time-to-live value, which specifies how long other servers should cache data from the name server (here 36,000 seconds or 10 hours).

There are several types of resource records, identified by the key word in field three of each record. You may present records in any order, but try to organize them for clarity. The NS (name server) record tells the hosts that query your server where the name servers for this domain can be found:

maxx.net. IN NS nova.maxx.net.

You must include in this list at least one name server, that is the name of the server specified in the SOA record. You can list multiple name servers for your domain. In fact, your domain should have at least two name servers. Your Internet service provider will probably allow you to use their name server as a secondary for your domain, but it must have the trailing dots!

maxx.net IN A 204.251.17.241

The first A record, which resolves a fully-qualified host name to an IP address, is a special one. It defines an IP address for unqualified queries, that is, queries for the host maxx.net.

Other A records like this one:

lucy IN A 204.251.17.242

provide name-to-address mapping for a specific named host. The domain defined in this file (maxx.net) is appended to the host name you show in the first field.

The CNAME records create aliases for existing hosts. These examples illustrate a few common uses:

www IN CNAME maxx.maxx.net. ftp IN CNAME maxx.maxx.net.

You can give a host any alias you like, and as many aliases as you want. The host needn't answer to that name, that is, the alias doesn't need to be the host's true name as reported by hostname or uname.

The other vital type of record is MX. This tells SMTP e-mail software where to send mail for each named host:

lucy IN MX 10 lucy.maxx.net.

When a remote host's mail delivery program sees an e-mail address in your domain, it will query your name server for its applicable MX record or records. Every user on your LAN can receive e-mail, even if not every host is running its own e-mail software. The MX record for lucy, for instance, could easily redirect e-mail to another host on the LAN.

The number (10 in this case) in the fourth field represents a preference value. If you define multiple MX records for a host, delivery is attempted to lower-preference value hosts first. The actual value isn't important, only its relationship to other preference values.

On larger LANs it's a good idea to create backup e-mail servers. Smaller LANs can simply rely on the fact that most SMTP mailers will retry deliveries to the site for three days before returning a message to its sender.

The line, shown commented out here, would arrange to redirect e-mail for all hosts in this domain to a single machine:

; ; All mail for net delivered to nova ; ;* IN MX 10 nova.maxx.net.

This is a very good idea for LANs that benefit from a central e-mail repository.

Address-to-Name Mapping

Also called reverse mapping, the zone.ADDR db file allows resolvers to post queries armed with only the IP address of a host. This reverse mapping is used, for example, by Internet server software that prefers to log host names rather than less informative IP addresses.

Address-to-name mapping data will be provided for a DNS server by PTR entries in its zone.ADDR files, one for every network served by this DNS server, and its zone.LOCAL file.

Each entry will indicate the IP address in reverse order, then the host name. For example, for host littledog.maxx.net, whose IP address is 204.251.17.249, in the zone.ADDR file it's PTR entry would look like:

249.17.251.204. IN PTR littledog.maxx.net.

Why is it backwards? Recall that DNS does its parsing from right to left, from most inclusive to most specific. For IP addresses, it needs to parse in the same direction. But IP addresses, from right to left, go from most specific to most inclusive. So the simple answer is to reverse the IP address in the NDS PTR records. Now DNS can parse in the same direction, and resolve in the same order — from most inclusive to most specific.

A shortcut in PTR records is often used. It looks like this:

249 IN PTR littledog.maxx.net.

If the dot is left off the IP address in the PTR record, DNS will complete the IP address with the IP address of the domain, specified in the file's SOA record. This is also true for A records in name-to-address mapping db files. If the dot is left off, DNS will automatically try to complete the name with the full domain name in this zone. Paying attention to the terminating dot is important.

For the zone.LOCAL file we describe the loopback address just as you would expect it, now that we know we have to reverse it. The PTR entry in the zone.LOCAL file would look like:

1.0.0.127. IN PTR localhost.

or, using the shortcut:

1 IN PTR localhost.

Only one line from named.conf remains to be discussed, the "cache" entry. This is a bit of a misnomer as it doesn't have anything to do with local caching. Instead, it defines the master root domain name servers for the Internet. You can retrieve this list from ftp://nic.ddn.mil/netinfo/root-servers.txt. You will need to check this site periodically to ensure you have the latest list.

This file lists the root domain servers in human-readable format. You'll need to reformat it for consumption by named. Here's what the cache file looks like:

; Servers from the root domain ; ftp://nic.ddn.mil/netinfo/root-servers.txt ; . 99999999 IN NS A.ROOT-SERVERS.NET . 99999999 IN NS B.ROOT-SERVERS.NET . 99999999 IN NS C.ROOT-SERVERS.NET . 99999999 IN NS D.ROOT-SERVERS.NET . 99999999 IN NS E.ROOT-SERVERS.NET . 99999999 IN NS F.ROOT-SERVERS.NET . 99999999 IN NS G.ROOT-SERVERS.NET . 99999999 IN NS H.ROOT-SERVERS.NET . 99999999 IN NS I.ROOT-SERVERS.NET

; Root servers by address

A.ROOT-SERVERS.NET 99999999 IN A 198.41.0.4 B.ROOT-SERVERS.NET 99999999 IN A 128.9.0.107 C.ROOT-SERVERS.NET 99999999 IN A 192.33.4.12 D.ROOT-SERVERS.NET 99999999 IN A 128.8.10.90 E.ROOT-SERVERS.NET 99999999 IN A 192.203.230.10 F.ROOT-SERVERS.NET 99999999 IN A 192.5.5.241 G.ROOT-SERVERS.NET 99999999 IN A 192.112.36.4 H.ROOT-SERVERS.NET 99999999 IN A 128.63.2.53 I.ROOT-SERVERS.NET 99999999 IN A 192.36.148.17

Here, the dot (.) refers to the root domain and the 99999999 means a very long time-to-live value. The TTL value is no longer used for caching because the data isn't discarded if it times out, but administrators generally keep it around because it does no harm.

Your site may not have access to the Internet or may have protected its connection via a firewall. Often in this type of DNS configuration, one or more machines will be designated as a root server. In this case, the cache file will contain a list of internal root servers, and not the official Internet master root domain servers.

Testing Your Name Server

Perform simple checks on your name server's health with nslookup. This utility is standard with every TCP/IP-network-aware version of UNIX. There are other similar tools available — see "List of Utilities" later in this section for details.

You can find the source code for dig at several anonymous FTP archive sites, including: ftp://ftp.wonderland.org/NetBSD/NetBSD-current/src/usr.sbin/named/dig/ for the NetBSD release. Use Archie to find other sites.

The nslookup utility can be used interactively, much like other programs, such as ftp. That is, if you invoke this program without command line arguments, it displays a prompt and waits for your command:

>server mpe3000

Default Name Server: mpe3000.cup.hp.com Address: 15.13.199.80

By default, nslookup performs queries based on host names you submit; just enter a host name after the prompt:

> romeo Server: mpe3000.cup.hp.com Address: 15.13.199.80

Name: romeo.cup.hp.com Address: 15.13.194.242

> 15.12.194.242 Server: mpe3000.cup.hp.com Address: 15.13.199.80

Name: romeo.cup.hp.com Address: 15.12.194.242

You can check the resource records information about name server:

> set type=ns > mpeworld Name Server: mpeworld.cup.hp.com Address: 15.13.199.80

origin = dns.cup.hp.com mail addr = dns-admin.dns.cup.hp.com serial = 96092255 refresh = 10800 (3 hours) retry = 3600 (1 hour) expire = 604800 (7 days) minimum ttl = 86400 (1 day)

---