https://wiki.archlinux.org/api.php?action=feedcontributions&user=Cengic&feedformat=atomArchWiki - User contributions [en]2024-03-19T08:31:00ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Syslog-ng&diff=748396Syslog-ng2022-09-25T22:06:06Z<p>Cengic: Setting "ForwardToSyslog=" to "no" disables forwarding to syslog.socket and the example is supposed to explain how to log to both journald and syslog-ng.</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Logging]]<br />
[[ja:Syslog-ng]]<br />
{{Related articles start}}<br />
{{Related|rsyslog}}<br />
{{Related articles end}}<br />
<br />
[[Wikipedia:syslog-ng|syslog-ng]] is a [[Wikipedia:syslog|syslog]] implementation which can take log messages from sources and forward them to destinations, based on powerful filter directives.<br />
<br />
{{Note|With [[systemd/Journal|systemd's journal]], syslog-ng is not needed by most users.}}<br />
<br />
== Overview ==<br />
<br />
syslog-ng takes incoming log messages from defined '[[#Sources|sources]]' and forwards them to the appropriate [[#Destinations|destinations]], based on powerful [[#Creating Filters for Messages|filter]] directives. In a typical simple set-up, syslog-ng will read messages from three sources:<br />
<br />
# the default {{ic|/dev/log}} device, where most logs are sent<br />
# syslog-ng "internal" log messages<br />
# {{ic|/proc/kmsg}} kernel messages<br />
<br />
Sources are defined using the "source" directive. These incoming messages are then filtered according to defined filters ("filter" keyword), i.e. according to originating program or log level, and sent to the appropriate "destination". Destinations include log files (e.g. {{ic|/var/log/messages.log}}), printing messages on a console and remote servers. The pivotal function is [[#Log Paths|log]]. This function defines which filters should be applied to a certain source, and where the resulting messages should be sent to.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|syslog-ng}} package.<br />
<br />
To use syslog-ng, [[start]]/[[enable]] {{ic|syslog-ng@default.service}}.<br />
<br />
=== systemd/journald integration ===<br />
<br />
syslog-ng pulls in the messages from the systemd journal by default. Keeping {{ic|1=ForwardToSyslog=no}} in {{ic|/etc/systemd/journald.conf}} is recommended in order to avoid the overhead associated with the socket and to avoid [https://github.com/balabit/syslog-ng/issues/314 needless error messages in the log]. If on the other hand you do not want to store your logs twice and turn ''journald'''s {{ic|1=Storage=none}}, you '''will''' need {{ic|1=ForwardToSyslog=yes}}, as ''syslog-ng'' tries to follow the 'journald' journal file.<br />
<br />
See [[#syslog-ng and systemd journal]] for more details.<br />
<br />
== Sources ==<br />
<br />
syslog-ng receives log messages from a source. To define a source you should follow the following syntax:<br />
source <identifier> { source-driver(params); source-driver(params); ... };<br />
<br />
You can look at the identifiers and source-drivers in the [https://www.syslog-ng.com/technical-documents official manuals]. <br />
This will follow the manual to explain the configuration file above. The unix-stream() source-driver opens the given AF_UNIX<br />
[[wikipedia:Berkeley_sockets|socket]] and starts listening on it for messages. <br />
The internal() source-driver gets messages generated by syslog-ng.<br />
<br />
Therefore, the following means: {{ic|src}} gets messages from the {{ic|/dev/log}} socket and syslog-ng.<br />
source src { unix-stream("/dev/log"); internal(); };<br />
<br />
The kernel sends log messages to {{ic|/proc/kmsg}} and the file() driver reads log messages from files. Therefore, the following means:<br />
kernsrc gets messages from file {{ic|/proc/kmsg}}<br />
source kernsrc { file("/proc/kmsg"); };<br />
<br />
In the default configuration file after emerging syslog-ng, the source is defined as:<br />
source src { unix-stream("/dev/log"); internal(); pipe("/proc/kmsg"); };<br />
<br />
Reading messages by {{ic|pipe("/proc/kmsg")}} gives a better performance but because it opens its argument in read-write mode can be a security<br />
hazard as the [https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.20/administration-guide/21#TOPIC-1121850 syslog-ng admin guide] states:<br />
<br />
"Pipe is very similar to the file() driver, but there are a few differences, for example pipe() opens its argument in read-write mode, therefore it is not recommended to be used on special files like {{ic|/proc/kmsg}}." (You can follow this discussion in [https://forums.gentoo.org/viewtopic-t-558161.html this post].)<br />
<br />
To open a port to read data from a remote server a source must be defined with this syntax:<br />
source s_net { udp(); };<br />
<br />
for UDP or<br />
source s_net { tcp(); };<br />
<br />
to receive log messages via TCP. Both listen on port 514.<br />
<br />
=== syslog-ng and systemd journal ===<br />
<br />
Starting with syslog-ng version 3.6.1 the default {{ic|system()}} source on Linux systems using systemd uses journald as its standard {{ic|system()}} source.<br />
<br />
If you wish to use both the journald and syslog-ng, ensure the following settings are in effect. For systemd-journald, in the {{ic|/etc/systemd/journald.conf}} file, {{ic|1=Storage=}} either set to {{ic|auto}} or unset (which defaults to auto) and {{ic|1=ForwardToSyslog=}} set to {{ic|yes}}. For {{ic|/etc/syslog-ng/syslog-ng.conf}}, you need the following {{ic|source}} stanza:<br />
<br />
{{bc|<nowiki><br />
source src {<br />
system();<br />
internal();<br />
};</nowiki>}}<br />
<br />
If, on the other hand, you wish ''not'' to retain the journald logs, but only syslog-ng's text logs, set {{ic|<nowiki>Storage=volatile</nowiki>}} in {{ic|/etc/systemd/journald.conf}}. This will store journald in ram. As of syslog-ng 3.6.3, syslog-ng is using journald as the system(); source so if you set {{ic|1=Storage=none}}, the systemd journal will drop all messages and '''not''' forward them to syslog-ng.<br />
<br />
After the change [[restart]] the {{ic|systemd-journald.service}} and {{ic|syslog-ng@default.service}} daemons.<br />
<br />
== Destinations ==<br />
<br />
In syslog-ng, log messages are sent to files. The syntax is very similar to sources:<br />
destination <identifier> {destination-driver(params); destination-driver(params); ... };<br />
<br />
You will be normally logging to a file, but you could log to a different destination-driver: pipe, Unix socket, TCP-UDP ports,<br />
terminals or to specific programs. Therefore, this means sending authlog messages to {{ic|/var/log/auth.log}}:<br />
destination authlog { file("/var/log/auth.log"); };<br />
<br />
If the user is logged in, {{ic|usertty()}} sends messages to the terminal of the specified user. If you want to send console messages<br />
to root's terminal if it is logged in:<br />
destination console { usertty("root"); };<br />
<br />
Messages can be sent to a pipe with {{ic|pipe()}}. The following sends xconsole messages to the pipe {{ic|/dev/xconsole}}.<br />
This needs some more configuration, so you could look at the sub-section xconsole below.<br />
destination xconsole { pipe("/dev/xconsole"); };<br />
<br />
To send messages on the network, use {{ic|udp()}}. The following will send your log data out to another server.<br />
destination remote_server { udp("10.0.0.2" port(514)); };<br />
<br />
== Creating Filters for Messages ==<br />
<br />
The syntax for the filter statement is:<br />
filter <identifier> { expression; };<br />
<br />
Functions can be used in the expression, such as the function {{ic|facility()}} which selects messages based on the facility codes. <br />
The Linux kernel has a few facilities you can use for logging. Each facility has a log-level; where debug is the most verbose,<br />
and panic only shows serious errors. You can find the facilities, log levels and priority names in {{ic|/usr/include/sys/syslog.h}}.<br />
To filter those messages coming from authorization, like <br />
''<nowiki>May 11 23:42:31 mimosinnet su(pam_unix)[18569]: session opened for user root by (uid=1000)</nowiki>'', use the following:<br />
filter f_auth { facility(auth); };<br />
<br />
The facility expression can use the boolean operators {{ic|and}}, {{ic|or}}, and {{ic|not}}, so the following filter<br />
selects those messages not coming from authorization, network news or mail:<br />
filter f_debug { not facility(auth, authpriv, news, mail); };<br />
<br />
The function {{ic|level()}} selects messages based on its priority level, so if you want to select informational levels:<br />
filter f_info { level(info); };<br />
<br />
Functions and boolean operators can be combined in more complex expressions. The following line filters messages with a priority level from<br />
informational to warning not coming from auth, authpriv, mail and news facilities:<br />
filter f_messages { level(info..warn) and not facility(auth, authpriv, mail, news); };<br />
<br />
Messages can also be selected by matching a regular expression in the message with the function {{ic|match("regex" value("TEMPLATE"))}}. For example:<br />
filter f_failed { match("failed" value("MESSAGE")); };<br />
<br />
here is a list of templates : <br />
"AMPM", "BSDTAG", "DATE, C_DATE, R_DATE, S_DATE", "DAY, C_DAY, R_DAY, S_DAY", "FACILITY", "FACILITY_NUM", "FULLDATE, C_FULLDATE, R_FULLDATE, S_FULLDATE", "FULLHOST", "FULLHOST_FROM", "HOUR, C_HOUR, R_HOUR, S_HOUR", "HOUR12, C_HOUR12, R_HOUR12, S_HOUR12", "HOST", "HOST_FROM", "ISODATE, C_ISODATE, R_ISODATE, S_ISODATE", "LEVEL_NUM", "LOGHOST", "MIN, C_MIN, R_MIN, S_MIN", "MONTH, C_MONTH, R_MONTH, S_MONTH", "MONTH_ABBREV, C_MONTH_ABBREV, R_MONTH_ABBREV, S_MONTH_ABBREV", "MONTH_NAME, C_MONTH_NAME, R_MONTH_NAME, S_MONTH_NAME", "MONTH_WEEK, C_MONTH_WEEK, R_MONTH_WEEK, S_MONTH_WEEK", "MSEC, C_MSEC, R_MSEC, S_MSEC", "MSG or MESSAGE", "MSGHDR", "MSGID", "MSGONLY", "PID", "PRI", "PRIORITY or LEVEL", "PROGRAM", "SDATA, .SDATA.SDID.SDNAME", "SEC, C_SEC, R_SEC, S_SEC", "SOURCEIP", "SEQNUM", "STAMP, R_STAMP, S_STAMP", "SYSUPTIME", "TAG", "TAGS", "TZ, C_TZ, R_TZ, S_TZ", "TZOFFSET, C_TZOFFSET, R_TZOFFSET, S_TZOFFSET", "UNIXTIME, C_UNIXTIME, R_UNIXTIME, S_UNIXTIME", "USEC, C_USEC, R_USEC, S_USEC", "YEAR, C_YEAR, R_YEAR, S_YEAR", "WEEK, C_WEEK, R_WEEK, S_WEEK", "WEEK_ABBREV, C_WEEK_ABBREV, R_WEEK_ABBREV, S_WEEK_ABBREV", "WEEK_DAY, C_WEEK_DAY, R_WEEK_DAY, S_WEEK_DAY", "WEEKDAY, C_WEEKDAY, R_WEEKDAY, S_WEEKDAY", "WEEK_DAY_NAME, C_WEEK_DAY_NAME, R_WEEK_DAY_NAME, S_WEEK_DAY_NAME".<br />
<br />
To filter messages received from a particular remote host, the {{ic|host()}} function must be used:<br />
filter f_host { host( "192.168.1.1" ); };<br />
<br />
== Log Paths ==<br />
<br />
syslog-ng connects sources, filters and destinations with log statements. The syntax is:<br />
log {source(s1); source(s2); ...<br />
filter(f1); filter(f2); ...<br />
destination(d1); destination(d2); ...<br />
flags(flag1[, flag2...]); };<br />
<br />
The following for example sends messages from {{ic|src}} source to {{ic|mailinfo}} destination filtered by {{ic|f_info}} filter.<br />
log { source(src); filter(f_mail); filter(f_info); destination(mailinfo); };<br />
<br />
== Tips and Tricks ==<br />
<br />
After understanding the logic behind syslog-ng, many possible and complex configuration are possible. Here there are some examples.<br />
<br />
=== Have syslog-ng reload the configuration file ===<br />
<br />
You can make syslog-ng re-evaluate the configuration file. You can do so manually by sending a {{ic|SIGHUP}} to the process, or [[reload]] {{ic|syslog-ng@default.service}}.<br />
<br />
=== Failover Logging to Remote Host ===<br />
<br />
This setup shows how to send the default unencrypted syslog packets across both TCP and UDP protocols, using the standard port (514) and an alternate port. This is sending the same output to the same machine 4 different ways to try and make sure packets make it. Mostly useful if you are debugging a remote server that fails to reboot. The different ports and protocols are to make it past any firewall filters or other network problems. Also useful for port-forwarding and using tunnels. Something like this setup is ideal to tunnel across an ssh connection that the prone-to-failover host initiates through a reverse connection.<br />
<br />
{{bc|<nowiki>#sending to a remote syslog server on TCP and UDP ports (not encrypted)<br />
destination askapache_failover_loghost {<br />
tcp("208.86.158.195" port(25214));<br />
udp("208.86.158.195" port(25214));<br />
udp("mysyslog1.dyndns.org" port(514));<br />
};<br />
log { <br />
source(src); <br />
destination(askapache_failover_loghost);<br />
};</nowiki><br />
}}<br />
<br />
And then on the loghost receiving these logs:<br />
<br />
{{bc|<nowiki>#a USB redirected console for flexible viewing<br />
destination debugging_console {<br />
file("/dev/ttyU1");<br />
};<br />
<br />
# listens on IP addresses and ports, sets the incoming settings<br />
source prone_to_failover_host {<br />
tcp(ip(208.86.158.195),port(25214));<br />
udp(ip(208.86.158.195) port(25214));<br />
<br />
udp(default-facility(syslog) default-priority(emerg));<br />
tcp(default-facility(syslog) default-priority(emerg));<br />
}<br />
<br />
# log it<br />
log {<br />
source(prone_to_failover_host); <br />
destination(debugging_console);<br />
};</nowiki><br />
}}<br />
<br />
=== Move log to another file ===<br />
<br />
In order to move some log from {{ic|/var/log/messages}} to another file:<br />
<br />
{{bc|<nowiki>#sshd configuration<br />
destination ssh { file("/var/log/ssh.log"); };<br />
filter f_ssh { program("sshd"); };<br />
log { source(src); filter(f_ssh); destination(ssh); };</nowiki><br />
}}<br />
<br />
=== Configuring as a loghost ===<br />
<br />
Configuring your system to be a loghost is quite simple. Drop the following into your configuration, and create the needed directory.<br />
With this simple configuration, log filenames will be based on the [[Wikipedia:FQDN|FQDN]] of the remote host,<br />
and located in {{ic|/var/log/remote/}}. After creating the remote directory, reload your syslog-ng configuration.<br />
<br />
{{bc|<nowiki>source net { udp(); };<br />
destination remote { file("/var/log/remote/${FULLHOST}-log"); };<br />
log { source(net); destination(remote); };</nowiki><br />
}}<br />
<br />
=== Improve Performance ===<br />
<br />
syslog-ng's performance can be improved in different ways:<br />
<br />
==== Write every so often ====<br />
<br />
It seems that the old {{ic|sync(X)}} '''option''' is called {{ic|flush_lines(X)}} now, where the writing to the file is buffered for {{ic|X}} lines. Default is 0 (no buffering).<br />
<br />
==== Avoid redundant processing and disk space ====<br />
<br />
A single log message can be sent to different log files several times. For example, in the initial configuration file, we have the following definitions:<br />
<br />
{{bc|<nowiki>destination cron { file("/var/log/cron.log"); };<br />
destination messages { file("/var/log/messages"); };<br />
filter f_cron { facility(cron); };<br />
filter f_messages { level(info..warn) <br />
and not facility(auth, authpriv, mail, news); };<br />
log { source(src); filter(f_cron); destination(cron); };<br />
log { source(src); filter(f_messages); destination(messages); };</nowiki><br />
}}<br />
<br />
The same message from the {{ic|cron}} facility will end up in both the {{ic|cron.log}} and {{ic|messages}} files. To change this behavior we can use the {{ic|final}} flag, <br />
ending up further processing with the message. Therefore, in this example, if we want messages from the {{ic|cron}} facility not ending up in the<br />
messages file, we should change the cron's log sentence by:<br />
<br />
log { source(src); filter(f_cron); destination(cron); flags(final); };<br />
<br />
another way is to exclude the {{ic|cron}} facility from {{ic|f_messages}} filter:<br />
filter f_messages { level(info..warn) and not facility(cron, auth, authpriv, mail, news); };<br />
<br />
=== PostgreSQL Destination ===<br />
<br />
This section will use two roles: {{ic|syslog}} and {{ic|logwriter}}. {{ic|syslog}} will be the administrator of the database {{ic|syslog}} and {{ic|logwriter}} will only be able to add records to the {{ic|logs}} table.<br />
<br />
No longer needed to create table for logs. syslog-ng will create automatically.<br />
psql -U postgres<br />
<br />
postgres=# CREATE ROLE syslog WITH LOGIN;<br />
postgres=# \password syslog # Using the \password function is secure because<br />
postgres=# CREATE ROLE logwriter WITH LOGIN;<br />
postgres=# \password logwriter # the password is not saved in history.<br />
postgres=# CREATE DATABASE syslog OWNER syslog;<br />
postgres=# \q # You are done here for the moment<br />
<br />
Edit {{ic|pg_hba.conf}} to allow {{ic|syslog}} and {{ic|logwriter}} to establish a connection to PostgreSQL.<br />
<br />
{{hc|/var/lib/postgres/data/pg_hba.conf|<br />
# TYPE DATABASE USER CIDR-ADDRESS METHOD<br />
<br />
host syslog logwriter 192.168.0.1/24 md5<br />
host syslog syslog 192.168.0.10/32 md5<br />
}}<br />
<br />
Then [[reload]] {{ic|postgresql.service}}. <br />
<br />
Edit {{ic|/etc/syslog-ng/syslog-ng.conf}} so that it knows where and how to write to PostgreSQL. syslog-ng will utilize the {{ic|logwriter}} role.<br />
<br />
{{bc|<nowiki>...<br />
#<br />
# SQL logging support<br />
#<br />
<br />
destination d_pgsql {<br />
sql(type(pgsql)<br />
host("127.0.0.1") username("logwriter") password("password")<br />
database("syslog")<br />
table("logs_${HOST}_${R_YEAR}${R_MONTH}${R_DAY}") #or whatever you want, example ${HOST}" for hosts, ${LEVEL}" for levels.. etc<br />
columns("datetime timestamp with time zone", "host varchar(32)", "program varchar(16)", "pid varchar(16)", "message varchar(200)")<br />
values("$R_ISODATE", "$HOST", "$PROGRAM", "$PID", "$MSG")<br />
indexes("datetime", "host", "program", "pid", "message"));<br />
};<br />
<br />
log { source(src); destination(d_pgsql); };</nowiki><br />
}}<br />
<br />
Finally, [[restart]] {{ic|syslog-ng.service}}.<br />
<br />
And check to see if things are being logged.<br />
psql -U logwriter -d syslog<br />
syslog=> SELECT * FROM <your table name> ORDER BY datetime DESC LIMIT 10;<br />
<br />
=== ISO 8601 timestamps ===<br />
<br />
'''Before''' :<br />
#logger These timestamps are not optimal.<br />
#tail -n 1 /var/log/messages.log<br />
Feb 18 14:25:01 hostname logger: These timestamps are not optimal.<br />
#<br />
<br />
Add {{ic|ts_format(iso);}} to {{ic|/etc/syslog-ng/syslog-ng.conf}} in the options section. Example:<br />
options {<br />
stats_freq (0);<br />
flush_lines (0);<br />
time_reopen (10);<br />
log_fifo_size (1000);<br />
long_hostnames(off); <br />
use_dns (no);<br />
use_fqdn (no);<br />
create_dirs (no);<br />
keep_hostname (yes);<br />
perm(0640);<br />
group("log");<br />
ts_format(iso); #make ISO-8601 timestamps<br />
#frac-digits(3); #optional time to nearest millisecond <br />
};<br />
<br />
Then [[reload]] {{ic|syslog-ng.service}}. <br />
<br />
'''After''' :<br />
#logger Now THAT is a timestamp!<br />
#tail -n 2 /var/log/messages.log<br />
Feb 18 14:25:01 hostname logger: These timestamps are not optimal.<br />
2010-02-18T20:23:58-05:00 electron logger: Now THAT is a timestamp!<br />
#<br />
<br />
=== RFC 3339 timestamps ===<br />
<br />
Same as above, except use {{ic|rfc3339}} instead of {{ic|iso}} for {{ic|ts_format}}<br />
<br />
=== Log Levels ===<br />
<br />
Log levels are defined separately for each logged facility in syslog-ng config. Available log levels are listed in /usr/include/sys/syslog.h :<br />
<br />
define LOG_EMERG 0 /* system is unusable */<br />
define LOG_ALERT 1 /* action must be taken immediately */<br />
define LOG_CRIT 2 /* critical conditions */<br />
define LOG_ERR 3 /* error conditions */<br />
define LOG_WARNING 4 /* warning conditions */<br />
define LOG_NOTICE 5 /* normal but significant condition */<br />
define LOG_INFO 6 /* informational */<br />
define LOG_DEBUG 7 /* debug-level messages */<br />
<br />
=== Macros and Variables ===<br />
<br />
Macros can be used in both templates, and in destination file names. [https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.20/administration-guide/60#TOPIC-1122008 Macros of syslog-ng OSE].<br />
<br />
The following code will write the log lines to {{ic|/var/log/test.log}} in the format of {{ic|<nowiki>macroname=value@</nowiki>}}. <br />
<br />
{{bc|<nowiki>template t_test { template("PROGRAM=$PROGRAM@PID=$PID@BSDTAG=$BSDTAG@TAG=$TAG@TAGS=$TAGS@FACILITY=$FACILITY@FACILITY_NUM=$FACILITY_NUM@LEVEL=$LEVEL@LEVEL_NUM=$LEVEL_NUM@PRI=$PRI@PRIORITY=$PRIORITY@FULLHOST=$FULLHOST@FULLHOST_FROM=$FULLHOST_FROM@HOST=$HOST@HOST_FROM=$HOST_FROM@LOGHOST=$LOGHOST@MSGHDR=$MSGHDR@MSGID=$MSGID@MSGONLY=$MSGONLY@MSG=$MSG@MESSAGE=$MESSAGE@SOURCE=$SOURCE@SOURCEIP=$SOURCEIP@SOURCE_IP=$SOURCE_IP@SEQNUM=$SEQNUM@UNIXTIME=$UNIXTIME@FULLDATE=$FULLDATE@ISODATE=$ISODATE@DATE=$DATE@STAMP=$STAMP@TZ=$TZ@TZOFFSET=$TZOFFSET@SEC=$SEC@MIN=$MIN@HOUR=$HOUR@HOUR12=$HOUR12@DAY=$DAY@WEEK=$WEEK@WEEK_DAY=$WEEK_DAY@WEEK_DAY_ABBREV=$WEEK_DAY_ABBREV@WEEK_DAY_NAME=$WEEK_DAY_NAME@MONTH=$MONTH@MONTH_ABBREV=$MONTH_ABBREV@MONTH_NAME=$MONTH_NAME@MONTH_WEEK=$MONTH_WEEK@YEAR=$YEAR@YEAR_DAY=$YEAR_DAY<br />
\n"); template_escape(no); };<br />
<br />
destination d_test { file("/var/log/test.log" template(t_test)); };<br />
<br />
log { source(s_local); destination(d_test); flags(final); };<br />
</nowiki>}}<br />
<br />
You can create your own value list as below once syslog-ng is restarted with:<br />
{{ic|<nowiki>tail /var/log/test.log|tr "@" "\n"</nowiki>}}<br />
<br />
{{bc|<nowiki><br />
PROGRAM=kernel<br />
PID=<br />
BSDTAG=4A<br />
TAG=04<br />
TAGS=.source.s_local<br />
FACILITY=kern<br />
FACILITY_NUM=0<br />
LEVEL=warning<br />
LEVEL_NUM=4<br />
PRI=4<br />
PRIORITY=warning<br />
FULLHOST=www.askapache.com<br />
FULLHOST_FROM=www.askapache.com<br />
HOST=www.askapache.com<br />
HOST_FROM=www.askapache.com<br />
LOGHOST=<br />
MSGHDR=kernel: <br />
MSGID=<br />
MSGONLY=Firewall: *INVALID* IN=eth0 OUT= MAC=00:00 SRC=x.x.x.x DST=198.101.159.98 LEN=40 TOS=0x00 PREC=0x00 TTL=113 ID=7730 DF PROTO=TCP SPT=52369 DPT=80 WINDOW=0 RES=0x00 ACK RST URGP=0 <br />
MSG=Firewall: *INVALID* IN=eth0 OUT= MAC=00:00 SRC=x.x.x.x DST=198.101.159.98 LEN=40 TOS=0x00 PREC=0x00 TTL=113 ID=7730 DF PROTO=TCP SPT=52369 DPT=80 WINDOW=0 RES=0x00 ACK RST URGP=0 <br />
MESSAGE=Firewall: *INVALID* IN=eth0 OUT= MAC=00:00 SRC=x.x.x.x DST=198.101.159.98 LEN=40 TOS=0x00 PREC=0x00 TTL=113 ID=7730 DF PROTO=TCP SPT=52369 DPT=80 WINDOW=0 RES=0x00 ACK RST URGP=0 <br />
SOURCE=s_local<br />
SOURCEIP=127.0.0.1<br />
SOURCE_IP=<br />
UNIXTIME=1369742458<br />
FULLDATE=2013 May 28 08:00:58<br />
ISODATE=2013-05-28T08:00:58-04:00<br />
DATE=May 28 08:00:58<br />
STAMP=2013-05-28T08:00:58-04:00<br />
TZ=-04:00<br />
TZOFFSET=-04:00<br />
SEC=58<br />
MIN=00<br />
HOUR=08<br />
HOUR12=<br />
DAY=28<br />
WEEK=21<br />
WEEK_DAY=3<br />
WEEK_DAY_ABBREV=Tue<br />
WEEK_DAY_NAME=Tuesday<br />
MONTH=05<br />
MONTH_ABBREV=May<br />
MONTH_NAME=May<br />
MONTH_WEEK=4<br />
YEAR=2013<br />
YEAR_DAY=148<br />
</nowiki>}}<br />
<br />
=== Receive and parse common syslog messages ===<br />
<br />
Starting from version 3.16 syslog-ng is capable to receive and parse messages on the most common ports with the most common parsers using the [https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.20/administration-guide/17#TOPIC-1121831 default-network-drivers()] source driver.<br />
* Default listening ports:<br />
** 514, both TCP and UDP, for RFC3164 (BSD-syslog) formatted traffic<br />
** 601 TCP, for RFC5424 (IETF-syslog) formatted traffic<br />
** 6514 TCP, for TLS-encrypted traffic<br />
* Automatic parsers:<br />
** RFC3164 message parser<br />
** RFC5424 message parser<br />
** [https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.20/administration-guide/68#TOPIC-1122040 Cisco parser]<br />
** Structured [https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.20/administration-guide/ewmm-intro EWMM parser]<br />
** Other application adapters (Splunk Common Information Model (CIM), iptables, or sudo)<br />
<br />
=== See Also ===<br />
<br />
* [[Netconsole]] A kernel module that sends all kernel log messages (i.e. [[dmesg]]) over the network to another computer, without involving user space (e.g. syslogd).<br />
<br />
== External Links ==<br />
<br />
* [https://www.syslog-ng.com/products/open-source-log-management/ syslog-ng OSE Main Page]<br />
* [https://github.com/balabit/syslog-ng syslog-ng OSE Project Page on GitHub]<br />
* [https://www.syslog-ng.com/technical-documents Portal to syslog-ng Documentation]<br />
** [https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.20/administration-guide The syslog-ng 3.20 Administrator Guide]<br />
** [https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.20/administration-guide/60#TOPIC-1122008 List of syslog-ng 3.20 Macros]<br />
* [https://www.syslog-ng.com/community/ syslog-ng Blogs]<br />
* [http://freshmeat.sourceforge.net/projects/syslog-ng/ syslog-ng Project Page on Freecode]<br />
* [[Gentoo:syslog-ng]]<br />
* [[Gentoo:Security Handbook/Logging]]<br />
* [https://www.pcwdld.com/what-is-syslog-including-servers-and-ports What is Syslog? Logging with PostgreSQL HOWTO]<br />
* [[Wikipedia:ISO 8601]]<br />
* [[RFC:3164|RFC 3164]] - The BSD syslog Protocol<br />
* [[RFC:5424|RFC 5424]] - The Syslog Protocol<br />
** [[RFC:5425|RFC 5425]] - Transport Layer Security (TLS) Transport Mapping for Syslog<br />
** [[RFC:5426|RFC 5426]] - Transmission of Syslog Messages over UDP<br />
** [[RFC:5427|RFC 5427]] - Textual Conventions for Syslog Management<br />
** [[RFC:5428|RFC 5428]] - MIB for PacketCable and IPCablecom-Compliant Devices<br />
* [[RFC:3339|RFC 3339]] - Date and Time on the Internet: Timestamps</div>Cengichttps://wiki.archlinux.org/index.php?title=User:Cengic&diff=503875User:Cengic2017-12-23T14:11:39Z<p>Cengic: </p>
<hr />
<div>I've been part of the Linux community since 1997 when I started out with Red Hat. I moved on looking for the perfect distro until I found Slackware. I've been Slack user for a decade but I've grown tired of the slow pace of development, I moved on to Arch as it fits my needs better.</div>Cengichttps://wiki.archlinux.org/index.php?title=User:Cengic&diff=66294User:Cengic2009-04-05T17:30:27Z<p>Cengic: </p>
<hr />
<div>I've been using Linux since 1997 when I started out with Red Hat. I moved on looking for the perfect distro until I found Slackware. I've been Slack user for a decade now but I've grown tired of the slow pace of development, I moved on to Arch as it fits my needs better.<br />
<br />
I'm looking forward to getting to know Arch and being a part of the community.<br />
<br />
Regards.</div>Cengichttps://wiki.archlinux.org/index.php?title=User:Cengic&diff=55622User:Cengic2008-12-16T03:30:07Z<p>Cengic: </p>
<hr />
<div>A recent Arch convert switching from Slackware. Clean init and easy text based configuration are some of the things I like about Arch. I particularly like the use of rc.conf and the design used for specific package configuration in conf.d. I also like the network profile system. I haven't seen anything as simple and useful in any other distro I have tried. And I have tried many :) <br />
<br />
I've been using Linux since 1997 when I started out with Red Hat, moving on looking for the perfect distro until I found Slackware. I've been Slack user for a decade now and I'm still using it on my desktop and workstation. The Arch is on my laptop since I'm spending more time on it nowadays.<br />
<br />
I'm looking forward to getting to know Arch better and being a part of the community.<br />
<br />
Regards.</div>Cengichttps://wiki.archlinux.org/index.php?title=User:Cengic&diff=55621User:Cengic2008-12-16T03:22:28Z<p>Cengic: </p>
<hr />
<div>Hi,<br />
<br />
I'm a new Arch user switching from Slackware. I tried Arch several times before but it wasn't ready for me. Now when I've tried it, it seems it has got a long way ahead. Nice clean init and easy text based configuration for all major subsystems. I particularly like the use of the rc.conf and the design used for it. I also love the network profile system. I haven't seen anything as simple and useful in any other distro I have tried. And I have tried many :) <br />
<br />
I've been using Linux since 1997 when I started out with Red Hat, moving on looking for the perfect distro until I found Slackware. I've been Slack user for a decade now and I'm still using it on my desktop and workstation. The Arch is on my laptop since I'm spending more time on it nowadays.<br />
<br />
I'm looking forward to getting to know Arch better and being a part of the community.<br />
<br />
Regards.</div>Cengichttps://wiki.archlinux.org/index.php?title=Map_Custom_Device_Entries_with_udev&diff=39995Map Custom Device Entries with udev2008-04-20T09:39:34Z<p>Cengic: </p>
<hr />
<div>[[Category:Hardware detection and troubleshooting (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
This information is basically mirrored from the gentoo wiki with some additional hints. Recently it was updated to reflect changes in udev >= 98 syntax.<br />
<br />
This process allows you to always map a specific device to the same <code>/dev</code> node. This can then be used in <code>fstab</code> to ensure you can always mount the device same device in exactly the same place - which is great for desktop shortcuts!<br />
<br />
<br />
==Get the udev info for your USB device==<br />
<br />
Make sure one of your target devices is plugged in and then run the following as root:<br />
udevinfo -a -p `udevinfo -q path -n /dev/sda`<br />
<br />
This gets the udev device info for the device on <code>/dev/sda</code> - if your device is not mapped to <code>/dev/sda</code> then obviously use the correct mapping. :)<br />
<br />
You should get some output like this:<br />
<pre><br />
<br />
Udevinfo starts with the device specified by the devpath and then<br />
walks up the chain of parent devices. It prints for every device<br />
found, all possible attributes in the udev rules key format.<br />
A rule to match, can be composed by the attributes of the device<br />
and the attributes from one single parent device.<br />
<br />
looking at device '/block/sda':<br />
KERNEL=="sda"<br />
SUBSYSTEM=="block"<br />
DRIVER==""<br />
ATTR{stat}==" 19 111 137 160 0 0 0 0 0 152 160"<br />
ATTR{size}=="2007040"<br />
ATTR{removable}=="1"<br />
ATTR{range}=="16"<br />
ATTR{dev}=="8:0"<br />
<br />
looking at parent device '/devices/pci0000:00/0000:00:02.2/usb1/1-5/1-5:1.0/host5/target5:0:0/5:0:0:0':<br />
KERNELS=="5:0:0:0"<br />
SUBSYSTEMS=="scsi"<br />
DRIVERS=="sd"<br />
ATTRS{ioerr_cnt}=="0x0"<br />
ATTRS{iodone_cnt}=="0x1c"<br />
ATTRS{iorequest_cnt}=="0x1c"<br />
ATTRS{iocounterbits}=="32"<br />
ATTRS{timeout}=="30"<br />
ATTRS{state}=="running"<br />
ATTRS{rev}=="1.20"<br />
ATTRS{model}=="01GB Tiny "<br />
ATTRS{vendor}=="Pretec "<br />
ATTRS{scsi_level}=="3"<br />
ATTRS{type}=="0"<br />
ATTRS{queue_type}=="none"<br />
ATTRS{queue_depth}=="1"<br />
ATTRS{device_blocked}=="0"<br />
ATTRS{max_sectors}=="240"<br />
<br />
looking at parent device '/devices/pci0000:00/0000:00:02.2/usb1/1-5/1-5:1.0/host5/target5:0:0':<br />
KERNELS=="target5:0:0"<br />
SUBSYSTEMS==""<br />
DRIVERS==""<br />
<br />
looking at parent device '/devices/pci0000:00/0000:00:02.2/usb1/1-5/1-5:1.0/host5':<br />
KERNELS=="host5"<br />
SUBSYSTEMS==""<br />
DRIVERS==""<br />
<br />
looking at parent device '/devices/pci0000:00/0000:00:02.2/usb1/1-5/1-5:1.0':<br />
KERNELS=="1-5:1.0"<br />
SUBSYSTEMS=="usb"<br />
DRIVERS=="usb-storage"<br />
ATTRS{modalias}=="usb:v4146pBA01d0100dc00dsc00dp00ic08isc06ip50"<br />
ATTRS{bInterfaceProtocol}=="50"<br />
ATTRS{bInterfaceSubClass}=="06"<br />
ATTRS{bInterfaceClass}=="08"<br />
ATTRS{bNumEndpoints}=="03"<br />
ATTRS{bAlternateSetting}==" 0"<br />
ATTRS{bInterfaceNumber}=="00"<br />
<br />
looking at parent device '/devices/pci0000:00/0000:00:02.2/usb1/1-5':<br />
KERNELS=="1-5"<br />
SUBSYSTEMS=="usb"<br />
DRIVERS=="usb"<br />
ATTRS{configuration}==""<br />
ATTRS{serial}=="14AB0000000096"<br />
ATTRS{product}=="USB Mass Storage Device"<br />
ATTRS{maxchild}=="0"<br />
ATTRS{version}==" 2.00"<br />
ATTRS{devnum}=="7"<br />
ATTRS{speed}=="480"<br />
ATTRS{bMaxPacketSize0}=="64"<br />
ATTRS{bNumConfigurations}=="1"<br />
ATTRS{bDeviceProtocol}=="00"<br />
ATTRS{bDeviceSubClass}=="00"<br />
ATTRS{bDeviceClass}=="00"<br />
ATTRS{bcdDevice}=="0100"<br />
ATTRS{idProduct}=="ba01"<br />
ATTRS{idVendor}=="4146"<br />
ATTRS{bMaxPower}==" 98mA"<br />
ATTRS{bmAttributes}=="80"<br />
ATTRS{bConfigurationValue}=="1"<br />
ATTRS{bNumInterfaces}==" 1"<br />
<br />
looking at parent device '/devices/pci0000:00/0000:00:02.2/usb1':<br />
KERNELS=="usb1"<br />
SUBSYSTEMS=="usb"<br />
DRIVERS=="usb"<br />
ATTRS{configuration}==""<br />
ATTRS{serial}=="0000:00:02.2"<br />
ATTRS{product}=="EHCI Host Controller"<br />
ATTRS{manufacturer}=="Linux 2.6.18-ARCH ehci_hcd"<br />
ATTRS{maxchild}=="6"<br />
ATTRS{version}==" 2.00"<br />
ATTRS{devnum}=="1"<br />
ATTRS{speed}=="480"<br />
ATTRS{bMaxPacketSize0}=="64"<br />
ATTRS{bNumConfigurations}=="1"<br />
ATTRS{bDeviceProtocol}=="01"<br />
ATTRS{bDeviceSubClass}=="00"<br />
ATTRS{bDeviceClass}=="09"<br />
ATTRS{bcdDevice}=="0206"<br />
ATTRS{idProduct}=="0000"<br />
ATTRS{idVendor}=="0000"<br />
ATTRS{bMaxPower}==" 0mA"<br />
ATTRS{bmAttributes}=="e0"<br />
ATTRS{bConfigurationValue}=="1"<br />
ATTRS{bNumInterfaces}==" 1"<br />
<br />
looking at parent device '/devices/pci0000:00/0000:00:02.2':<br />
KERNELS=="0000:00:02.2"<br />
SUBSYSTEMS=="pci"<br />
DRIVERS=="ehci_hcd"<br />
ATTRS{broken_parity_status}=="0"<br />
ATTRS{enable}=="1"<br />
ATTRS{modalias}=="pci:v000010DEd00000068sv00001043sd00000C11bc0Csc03i20"<br />
ATTRS{local_cpus}=="f"<br />
ATTRS{irq}=="17"<br />
ATTRS{class}=="0x0c0320"<br />
ATTRS{subsystem_device}=="0x0c11"<br />
ATTRS{subsystem_vendor}=="0x1043"<br />
ATTRS{device}=="0x0068"<br />
ATTRS{vendor}=="0x10de"<br />
<br />
looking at parent device '/devices/pci0000:00':<br />
KERNELS=="pci0000:00"<br />
SUBSYSTEMS==""<br />
DRIVERS==""<br />
<br />
</pre><br />
<br />
Bit too much information! The only bit of this you actually need is the <code>ATTRS{serial}</code> part - so now you know what the above command does just grep out the bit you want in future cases:<br />
<br />
udevinfo -a -p `udevinfo -q path -n /dev/sda` | grep ATTRS{serial}<br />
<br />
output:<br />
<br />
ATTRS{serial}=="14AB0000000096"<br />
ATTRS{serial}=="0000:00:02.2"<br />
<br />
Hmm, two serials. Which one to use?<br />
<br />
udevinfo -a -p `udevinfo -q path -n /dev/sda` | grep ATTRS{product}<br />
<br />
and we get<br />
<br />
ATTRS{product}=="USB Mass Storage Device"<br />
ATTRS{product}=="EHCI Host Controller"<br />
<br />
So, we need to use first serial.<br />
<br />
<br />
==Create a udev rule==<br />
<br />
You then use the <code>ATTRS{serial}</code> in a udev rule as follows:<br />
<br />
Note: The convention for Arch Linux is to place custom rules into <code>/etc/udev/rules.d/00.rules</code><br />
You may, however create a file with a different name. Just remember that udev processes these files in alphabetical order.<br />
<br />
BUS=="usb", ATTRS{serial}=="14AB0000000096", KERNEL=="sd?1", NAME="%k", SYMLINK+="usbdrive", GROUP="storage"<br />
<br />
<br />
==Create an fstab entry and mount point==<br />
<br />
Create a directory:<br />
<br />
mkdir /mnt/usbdrive<br />
<br />
In your <code>/etc/fstab</code>, create an entry like this:<br />
<br />
/dev/usbdrive /mnt/usbdrive vfat rw,noauto,group,flush,quiet,nodev,nosuid,noexec,noatime,dmask=000,fmask=111 0 0<br />
<br />
Additionally, depending on your locale preferences, add something like <code>codepage=866,iocharset=utf-8</code> to be able to see non-Latin filenames correctly.<br />
<br />
Now root or any user who belongs to the <code>storage</code> group can mount the USB stick by simply doing<br />
<br />
mount /mnt/usbdrive<br />
<br />
BTW, all the last 3 additional mount options are meant to increase your system's security, e.g. they will prevent you running an executable file directly from the USB drive.<br />
<br />
To allow non-root users to access to USB stick do<br />
gpasswd -a user1 storage<br />
gpasswd -a user2 storage<br />
<br />
==Restart udev==<br />
<br />
to test your updated rules you can run:<br />
udevcontrol reload_rules<br />
<br />
Only if really needed, you may restart udev like this. As root, run those 3 commands:<br />
/etc/./start_udev<br />
mount /dev/pts<br />
mount /dev/shm<br />
<br />
==Examples==<br />
<br />
Here are some examples from my system. My devices sometimes mount on <code>sda</code> or <code>sda1</code> so I have two rules for each - this is a work around for device not found problems. The sda node is also needed for disk-level activities e.g. <code>fdisk /dev/sda</code>.<br />
<br />
This always maps my disgo USB pen to <code>/dev/usbpen</code> which I then map in fstab to mount on <code>/mnt/usbpen</code><br />
<br />
# Symlink USB pen<br />
SUBSYSTEMS=="usb", ATTRS{serial}=="1730C13B18000B84", KERNEL=="sd?", NAME="%k", SYMLINK+="usbpen", GROUP="storage"<br />
SUBSYSTEMS=="usb", ATTRS{serial}=="1730C13B18000B84", KERNEL=="sd?1", NAME="%k", SYMLINK+="usbpen", GROUP="storage"<br />
<br />
If you have a device with with multiple partitions, the following example maps the device to <code>/dev/usbdisk</code>, and partitions 1, 2, 3 etc. to <code>/dev/usbdisk1</code>, <code>/dev/usbdisk2</code>, <code>/dev/usbdisk3</code> etc.<br />
<br />
# Symlink multi-part device<br />
SUSSYSTEMS=="usb", ATTRS{serial}=="1730C13B18000B84", KERNEL=="sd?", NAME="%k", SYMLINK+="usbdisk", GROUP="storage"<br />
SUBSYSTEMS=="usb", ATTRS{serial}=="1730C13B18000B84", KERNEL=="sd?[1-9]", NAME="%k", SYMLINK+="usbdisk%n", GROUP="storage"<br />
<br />
These rules are equivalent to the following one:<br />
<br />
# Symlink multi-part device<br />
SUBSYSTEMS=="usb", ATTRS{serial}=="1730C13B18000B84", KERNEL=="sd*", NAME="%k", SYMLINK+="usbdisk%n", GROUP="storage"<br />
<br />
You can also omit the NAME and GROUP statements, so that the defaults from <code>udev.rules</code> are used. So the shortest and simplest solution would be adding this rule:<br />
<br />
# Symlink multi-part device<br />
SUBSYSTEMS=="usb", ATTRS{serial}=="1730C13B18000B84", KERNEL=="sd*", SYMLINK+="usbdisk%n"<br />
<br />
This always maps our Olympus digicam to <code>/dev/usbcam</code> which I then map in fstab to mount on <code>/mnt/usbcam</code><br />
<br />
# Symlink USB camera<br />
SUBSYSTEMS=="usb", ATTRS{serial}=="000207532049", KERNEL=="sd?", NAME="%k", SYMLINK+="usbcam", GROUP="storage"<br />
SUBSYSTEMS=="usb", ATTRS{serial}=="000207532049", KERNEL=="sd?1", NAME="%k", SYMLINK+="usbcam", GROUP="storage"<br />
<br />
And this maps my Packard Bell MP3 player to <code>/dev/mp3player</code><br />
<br />
# Symlink MP3 player<br />
SUBSYSTEMS=="usb", ATTRS{serial}=="0002F5CF72C9C691", KERNEL=="sd?", NAME="%k", SYMLINK+="mp3player", GROUP="storage"<br />
SUBSYSTEMS=="usb", ATTRS{serial}=="0002F5CF72C9C691", KERNEL=="sd?1", NAME="%k", SYMLINK+="mp3player", GROUP="storage"<br />
<br />
To map your own usb key to <code>/dev/mykey</code> and all of other keys to <code>/dev/otherkey</code><br />
<br />
# Symlink USB keys<br />
SUBSYSTEMS=="usb", ATTRS{serial}=="insert serial key", KERNEL=="sd?1", NAME="%k", SYMLINK+="mykey"<br />
SUBSYSTEMS=="usb", KERNEL=="sd?1", NAME="%k", SYMLINK+="otherkey"<br />
<br />
Note the order of the lines. Since all the usb keys should create the /dev/sd<a||b> node, udev will first check if it is your own usb key, defined with the serial number. But if you plug another key witch you don't know the serial number, it will create a node too, with a generic name "otherkey". That rule should be the last one your rules file.<br />
<br />
<br />
This is an example how to distinguish USB HDD drive and USB sticks:<br />
<br />
BUS=="usb", ATTRS{product}=="USB2.0 Storage Device", KERNEL=="sd?", NAME="%k", SYMLINK+="usbdisk", GROUP="storage"<br />
BUS=="usb", ATTRS{product}=="USB2.0 Storage Device", KERNEL=="sd?[1-9]", NAME="%k", SYMLINK+="usbdisk%n", GROUP="storage"<br />
BUS=="usb", ATTRS{product}=="USB Mass Storage Device", KERNEL=="sd?1", NAME="%k", SYMLINK+="usbflash", GROUP="storage"<br />
<br />
Note that this udev rule doesn't use serials at all.</div>Cengichttps://wiki.archlinux.org/index.php?title=User:Cengic&diff=39169User:Cengic2008-03-25T23:30:28Z<p>Cengic: </p>
<hr />
<div>Hi,<br />
<br />
My name is Goran Cengic and I'm a new Arch user switching from Slackware. I tried Arch several times before but it wasn't ready for me. Now when I've tried it, it seems it has got a long way ahead. Nice clean init and easy text based configuration for all major subsystems. I particularly like the use of the rc.conf and the design used for it. I also love the network profile system. I haven't seen anything as simple and useful in any other distro I have tried. And I have tried many :) <br />
<br />
I've been using Linux since 1997 when I started out with Red Hat, moving on looking for the perfect distro until I found Slackware. I've been Slack user for a decade now and I'm still using it on my desktop and workstation. The Arch is on my laptop since I'm spending more time on it nowadays.<br />
<br />
I'm looking forward to getting to know Arch better and being a part of the community.<br />
<br />
Regards.</div>Cengichttps://wiki.archlinux.org/index.php?title=Hibernate-script&diff=39168Hibernate-script2008-03-25T23:26:23Z<p>Cengic: </p>
<hr />
<div>[[Category:Power management (English)]]<br />
[[Category:Laptops (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
This article describes how to suspend a computer (usually a laptop) to disk. This means that all the running processes are saved to the hard drive and the power is completely shut down. The article discusses the two main methods to accomplish this task, that is userspace suspension (uswsusp) and tuxonice (formerly known as suspend2). See the [http://suspend.sourceforge.net/ ususpend website] and the [http://www.tuxonice.net/ tuxonice website] for complete documentation. There is a third method: using the kernelspace functionalities of the vanilla kernel. However, this method is the least developed, the slowest and the less reliable. On the contrary, tuxonice and ususpend are competing in features and stability. The only method to decide which method is better for you is to try both of them. From a general point of view, we can say that uswsusp does not force you to patch, configure and compile a kernel, while tuxonice does. However, tuxonice can be used without an initrd/initramfs, while using ususpend without an initrd/initramfs is discouraged; moreover, tuxonice allows you to suspend on a regular file if you have not a swap partition, while uswsusp give this possibility only if you run an experimental and unstable mm kernel.<br />
<br />
It is important to distinguish the core method of suspension to disk from the userspace application which you use to hibernate your machine to disk. A userspace application is required because the large majority of the laptops require some quirks in order to accomplish a proficient, successful hibernation cycle: unloading modules, restarting services, unmount windows partitions and usb keys, and so on.<br />
<br />
There are two widely used userspace applications for this purpose: [[pm-utils]] and hibernate-script. You can find both of them in the extra repo. However, since in this guide we need to describe two different, competing core methods, we will focus on the hibernate-script, since only this script allows the user to choose the core method he prefers. On the contrary, [[pm-utils]], at least in the version actually distributed by arch, forces you silently to use the old vanilla method. On the other side, the script, developed by the tuxonice development team, can be used nonetheless also to hibernate your machine with the ususpend method, and even to suspend the machine to ram (actually it is an excellent tool also for this task, but we are not going to discuss this aspect in this document, see [[Suspend to RAM]]).<br />
<br />
If you prefer to use pm-utils, refer to the specific [[pm-utils|wiki article]]. You should note that the pm-utils-opensuse package includes some patches from opensuse which allow the user to choose uswsusp as a core method. In the web you can find other patches which allow you to use tuxonice as a method. The upcoming release of pm-utils will include all these patches and pm-utils will be a serious competitor of the hibernate-script. Nonetheless, the hibernate-script is still much more configurable and documented, so this guide still assumes that you are using it (although it is very easy to translate each info for pm-utils).<br />
<br />
Thus:<br />
<br />
# pacman -S hibernate-script<br />
<br />
The discussion will be articulated in four parts. First of all, we will discuss the userspace method, secondly the tuxonice one, thirdly we will see how to use the power of the hibernate-script in order to circumvent some problems which could impair your ability to accomplish successful suspend/resume cycles. These last tips can be used with both methods. On the contrary, the first two parts will include instructions to use the hibernate-script in order to accomplish the basic operations with the two methods. In the fourth and last part, we will see how to combine suspension to disk and [[Suspend to RAM]] . <br />
<br />
When there is the need to modify the configuration of the bootloader, we will be always under the assumption that you use grub, but it should not be difficult to act analogously on the configuration of lilo.<br />
<br />
=Uswsusp method=<br />
<br />
The userspace method lets you resort to some advanced suspension abilities included in vanilla kernels > 2.6.17. You need two userspace tools, called s2disk and resume, which do what their names say. They are both included in the uswsusp package (which includes also s2ram, see [[Suspend to RAM]] ). You can find uswsusp in the AUR. The package in the AUR includes also an initramfs hook which allows you to resume properly using an initramfs.<br />
<br />
==Obtaining uswsusp==<br />
The first thing to do is to download the tarball from the AUR page. Compile the source and create the package with makepkg and install it with pacman -U.<br />
<br />
<br />
==Editing /etc/suspend.conf==<br />
On the contrary, you need to edit the s2disk configuration file, called /etc/suspend.conf. It is essential that you modify the resume device parameter:<br />
<br />
resume device = /dev/sda3<br />
<br />
It needs to point to your swap partition: in this case, the third partition of a primary pata-sata drive. It is also a good thing to enable compression, because this speeds up greatly your suspension/resume routine.<br />
<br />
Note that it is important that this configuration file be edited *before* recreating the initramfs (done below). Presently, the initramfs build process reads this configuration file, and embeds the current resume parameter. If not changed from the default '<path_to_resume_device_file>', this causes problems such as seeing, on bootup:<br />
<br />
# Could not stat the resume device file '<path_to_resume_device_file>'<br />
# Please type in the full path name to try again or press ENTER to boot the system.<br />
<br />
If you have experiencing this problem, simply edit the file as appropriate, and then rebuild the initramfs.<br />
<br />
==Recreate the intramfs==<br />
Now you need to recreate an initramfs with the new hook. So edit the /etc/mkinitcpio.conf file. In the HOOKS list add the uresume hook (it is different from the resume hook, which is on the contrary required by the tuxonice method). You should put it immediately before the filesystem hook. When the hook is executed the device file for the swap partition (which you have defined in /etc/suspend.conf) needs to exist (the standard udev hook will take care of this). Now proceed to regenerate your initramfs :<br />
<br />
# mkinitcpio -k `uname -r` -g /boot/kernel26.img<br />
<br />
You need to adjust this command according to the kernel you plan to use and the name of the initramfs in the grub configuration. Anyway you should not need to modify anything in the grub configuration.<br />
<br />
==Support for encryption==<br />
The package in the AUR does already support encryption. You need to:<br />
* generate a key with the suspend-keygen utility included in the uswsusp package;<br />
* write the name of the key in /etc/suspend.conf;<br />
* uncomment or add the following line in /etc/suspend.conf<br />
<br />
encrypt = y<br />
RSA key file = <path_to_keyfile><br />
* build a new initramfs with the uresume hook just before the filesystem one.<br />
<br />
==Support for splash screens and suspension to file==<br />
<br />
The AUR package does not provide support for splash screens: uswsusp would support splashy and fbsplash, but you need to modify the PKGBUILD in order to recompile uswsusp with libsplashy or fbsplash support: see the HOWTO and README in the source tarball for details.<br />
<br />
Please note that uswsusp can also suspend to a file, but only if you use an experimental mm-patched kernel. If you want to suspend to file, tuxonice is probably the way to go. In the case you like experimental things, see the instructions in the HOWTO of the uswsusp source tarball.<br />
<br />
==Suspending==<br />
<br />
Now you could try to suspend directly calling s2disk from the command line:<br />
<br />
# s2disk<br />
<br />
However, this is highly likely to fail, because some services could need to be stopped, some modules unloaded, etc. Thus it is probably necessary to resort to a userspace tool which calls internally s2disk. The hibernate-script does this. See [[Suspend to Disk#Editing /etc/hibernate/hibernate.conf|below]] about details for defining the ususpend-disk method as default in /etc/hibernate/hibernate.conf. For the moment being, remember that you can define specific options in /etc/hibernate/ususpend-disk.conf and, after having configured also /etc/hibernate/common.conf, you can suspend to disk with the uswsusp method with the following command:<br />
<br />
# hibernate -F /etc/hibernate/ususpend-disk.conf <br />
<br />
=Tuxonice method=<br />
<br />
==Obtaining tuxonice==<br />
Tuxonice consists of a kernel patch, plus a user interface. Only the kernel patch is necessary, the user interface provides merely a semi-graphical interface displayed during the hibernation/resume cycle. <br />
<br />
Archlinux used to deliver a binary tuxonice-patched kernel, but none of the devs want currently to maintain it. <br />
<br />
However you can use the kernel26tuxonice in AUR unsupported. It automatizes all the patch routine, the compilation and installation of the kernel, the regeneration of the initramfs with an appropriate hook. <br />
<br />
Otherwise, you need to patch, configure and compile your own kernel. You can do this either with the ABS method (starting from the arch default kernel PKGBUILD and adding the tuxonice patchset, or with the plain, old, reliable, venerable routine of <br />
<br />
# make menuconfig<br />
# make<br />
# make modules_install<br />
# cp arch/i386/boot/bzImage /boot/kernel-tuxonice-2.6.*<br />
<br />
See [[Kernel Compilation From Source]] and [[Kernel Compilation with ABS]] for instructions.<br />
In both cases, you need to configure the options added by the patchset, which you can find in the ACPI section of make menuconfig. Anyway, the defaults should be suitable for the large majority of scenarios. You can also hardcode in the kernel the path of your swap partition. In this case you can skip the below [[Suspend to Disk#Editing the Grub menu.lst]] .<br />
<br />
Please note that, if you spend the time to reconfigure completely the kernel (and in particular if you compile into the kernel the stuff necessary to boot your machine), you can be dispensed by the necessity to generate and use an initramfs: tuxonice will be able to resume properly also without an initrd/initramfs.<br />
<br />
==Editing the Grub menu.lst==<br />
Before your can use the suspend function, you need to boot your computer with the "resume" parameter, unless you have hardcoded your swap partition during the kernel configuration. The resume parameter points to the swap partition or swap file. The parameter is a kernel boot parameter, that is it should be added, if you use GRUB, to the line of /boot/grub/menu.lst where the location of your kernel is specified. <br />
For example:<br />
<br />
# tuxonice kernel<br />
title ArchLinux<br />
kernel /boot/kernel-tuxonice-2.6 root=/dev/hda2 resume=swap:/dev/hda3<br />
initrd /boot/tuxonice.img<br />
<br />
This assumes that you installed Archlinux onto the second hard drive partition, that your swap partition is the third, that you have not a separate /boot partition and that you are using an initrd. Adjust accordingly to your case.<br />
<br />
==Recreating the initramfs==<br />
<br />
If you use an initramfs, you need to add the tuxonice hook (which is different from the uresume used by uswsusp and by the resume hook for vanilla kernel suspension) in the HOOKS in the configuration of mkinitcpio. The hook is provided by the tuxoniceinitcpio package in AUR unsupported. This package is a dependency of kernel26tuxonice and is applied by default by kernel26tuxonice. Once you have added the tuxonice hook, you need to regenerate your initramfs, with a command like the following:<br />
<br />
# mkinitcpio -k kernel-tuxonice-2.6 -g /boot/tuxonice.img<br />
<br />
==Using userui - a user interface for tuxonice==<br />
<br />
Optionally, you can use a text or fbsplash interface with a progress bar with tuxonice. To do this, install the userui package in the extra repo:<br />
<br />
# pacman -S userui<br />
<br />
In ''/etc/hibernate/suspend2.conf'', configure the user interface:<br />
<br />
## Specify a userui like this:<br />
# text interface<br />
ProcSetting user_interface/program /usr/sbin/tuxoniceui_text<br />
<br />
or<br />
<br />
## Specify a userui like this:<br />
# fbsplash interface interface<br />
ProcSetting user_interface/program /usr/sbin/tuxoniceui_fbsplash<br />
<br />
The ''fbsplash'' interface also needs a fbsplash theme in ''/etc/splash/suspend2/''.<br />
<br />
The text interface may be good for debugging suspend2, as it displays some messages.<br />
You won't see a user interface for the first few seconds of the resume process unless you add the ''userui'' hook to your mkinitcpio configuration and regenerate your initramfs, but this is also optional.<br />
<br />
==Suspending and Resuming==<br />
<br />
Now you need to tweak the hibernate script. See [[Suspend to Disk#Editing /etc/hibernate/hibernate.conf|below]] for instructions about defining the tuxonice method as the default hibernation method. <br />
The specific file is /etc/hibernate/suspend2.conf (the hibernate-script still uses the old name of tuxonice):<br />
<br />
Make sure that the following lines are uncommented and appropriately configured:<br />
UseSuspend2 yes<br />
Reboot no<br />
EnableEscape yes<br />
DefaultConsoleLevel 1<br />
Compressor lzf<br />
<br />
Encryptor none<br />
<br />
Once you have tweaked what you want/need (also in /etc/hibernate/common.conf), you can try tuxonice hibernation with the following method:<br />
<br />
# hibernate -F /etc/hibernate/suspend2.conf<br />
<br />
You can abort a suspend cycle if you press the escape key. If you press a capital r, you will force the system to reboot after hibernation.<br />
If all goes well, you should be able to resume using the same Grub menu selection. If you make that option the default for Grub, you will always default to resuming if a resume image is available. '''Do never use a different kernel to resume than you used to suspend! If pacman updates your kernel, don't suspend before you have rebooted properly.''' It is recommended that you test the suspend/hibernate from a text console first and then once you have confirmed that it works try it from within X.<br />
<br />
You can make this practice safer adding the hibernate-cleanup service to your SERVICES array in /etc/rc.conf. This script will make sure that any stale image is deleted from your swap partition at boot time. This should make your system safe also in the case that you have chosen the mistaken kernel at the grub prompt. The hibernate-cleanup service is included in the hibernate-script package.<br />
<br />
== References ==<br />
<br />
*The [http://www.tuxonice.net tuxonice website] and the [http://wiki.tuxonice.net/ tuxonice wiki] are excellent sources of documentation.<br />
*There is a good [http://gentoo-wiki.com/HOWTO_Software_Suspend_v2 Gentoo wiki article] that covers a lot of the same material.<br />
<br />
<br />
=Hibernate tricks with the hibernate.script=<br />
<br />
This is a brief overview of the hibernate script. If you want to tweak it further, examine the ''common.conf'' and ''suspend2.conf'' files further and read the excellent and exhaustive man pages for hibernate and hibernate.conf.<br />
<br />
==Editing /etc/hibernate/hibernate.conf==<br />
<br />
In order to call directly the hibernate command without the -F option, you need to define your preferred hibernation method. This should be done in this file. If you list several methods, the first one will be used. Note that ''hibernate'' can also be used with [[Suspend to RAM]] or vanilla swsusp, but this is not part of this HOWTO).<br />
<br />
Then either:<br />
<br />
TryMethod ususpend-disk.conf<br />
<br />
or: <br />
<br />
TryMethod suspend2.conf<br />
<br />
==Editing /etc/hibernate/common.conf==<br />
<br />
The options in this file are used with any hibernation method (actually, the file is sourced by the configuration files of each method) and also by [[Suspend to RAM]] when accomplished with the hibernate-script. This file is complex and well commented. The man page hibernate.conf describes adequately all the options. Here, we can only stress the most commonly useful parts.<br />
<br />
Uncomment the lines for any filesystems that have the potential to change while your computer is suspended (for example shared partitions with windows like vfat or ntfs ones). They will be remounted upon resume. Otherwise you would risk corrupting the filesystems.<br />
<br />
### filesystems<br />
# Unmount /nfsshare /windows /mnt/sambaserver<br />
# UnmountFSTypes smbfs nfs<br />
# UnmountGraceTime 1<br />
# Mount /windows<br />
<br />
If you don't explicitly restore the volume levels, ALSA may have the sound channels muted after resuming. If this happens, look for<br />
<br />
### services<br />
<br />
in /etc/hibernate/common.conf and change the line just below to<br />
<br />
RestartServices alsa<br />
<br />
The alsa service will be stopped before suspension and restarted after resuming: the sound channels and volumes will be as before.<br />
You may want to restart other problematic services here.<br />
<br />
A common issue is that some drivers do not support suspension, that is they do not work properly after a suspension cycle or even they prevent the system from suspending or resuming properly. <br />
In these cases (which should be reported - at least for modules in the vanilla kernel - to the suspend-devel@lists.sourceforge.net mailing list, so that they can be fixed upstream) you can unload the module before suspension and reload it after resuming: the hibernate-script can automatize this routine with the LoadModules and UnloadModules options. Actually, the hibernate-script already unload some problematic modules, listed in /etc/hibernate/blacklisted-modules, so you can also add the modules in that file.<br />
<br />
<br />
To re-connect to networks after rebooting, you may want to add<br />
OnResume 25 netcfg2 -a<br />
OnResume 20 netcfg-auto-wireless <your-network-interface><br />
This will disconnect from all networks, then should automatically choose the correct one. If you use another way to connect to a network (such as netcfg2 <profile-name> then of-course, put that there instead.<br />
<br />
If you need/want to eject all PcCards before suspending and reinsert them after resuming, change the ''EjectCards'' setting in ''common.conf'':<br />
<br />
### pcmcia<br />
EjectCards yes<br />
<br />
This is necessary on some laptops, if the pccards stop working after resume.<br />
<br />
Finally, the most problematic aspect is constituted by the video card: its status needs often to be restored after resuming. In other cases, it is necessary to switch from X to the console.<br />
The following options in /etc/hibernate/common.conf will probably fix these issues (whose symptom could be a frozen machine or only a black display after resuming):<br />
<br />
### vbetool<br />
#EnableVbetool yes<br />
#RestoreVbeStateFrom /var/lib/vbetool/vbestate<br />
#VbetoolPost yes<br />
# RestoreVCSAData yes<br />
<br />
### xhacks<br />
#SwitchToTextMode yes<br />
#UseDummyXServer yes<br />
#DummyXServerConfig xorg-dummy.conf<br />
<br />
You can uncomment one or many of them in order to see if the problem is solved. In order to use the first block of options, you need to install the vbetool package from the extra repository. Each of the option is documented in man hibernate.conf. <br />
Please note that it is very important to try all the different combinations of these options before than anything else, becaause the problems with the display are the most common source of troubles in a suspension cycle.<br />
<br />
== NVidia specific settings ==<br />
If you have an NVidia graphics card and are using the binary driver by NVidia with an AGP card, you have to add the following line to your /etc/X11/xorg.conf:<br />
<br />
Option "NvAGP" "1"<br />
<br />
NVidia also suggest this setting for the hibernate script:<br />
<br />
ProcSetting extra_pages_allowance 0<br />
<br />
to the file /etc/hibernate/common.conf. This setting also seems to help with the binary ATI driver. At last, you need to uncomment the nvidia module in /etc/hibernate/blacklisted-modules.<br />
<br />
== Suspending with fglrx ==<br />
Following addition to /etc/hibernate/suspend2.conf is required:<br />
<br />
# For fglrx<br />
ProcSetting extra_pages_allowance 20000<br />
<br />
== Dropping Disk Caches ==<br />
<br />
As a way to speed up suspending, you can free the memory used for disk caches. so there will be less to write to the disk. The downside is the risk of crashing your system. but I have had no trouble with it so far, while reducing the size of the suspended image by half. Just run this before hibernating:<br />
<br />
sync; echo 3 > /proc/sys/vm/drop_caches<br />
[http://www.linuxinsight.com/proc_sys_vm_drop_caches.html drop_caches introduction]<br />
<br />
=Combining suspend to disk with suspend to RAM=<br />
<br />
If your motherboard or laptop supports [[Suspend to RAM]], you can combine it with suspend2. This will result in the following behavior:<br />
<br />
* When you call hibernate, your system will suspend to disk and after that suspend to RAM instead of powering down.<br />
* When you turn your system back on, it will resume directly from RAM (which only takes a few seconds)<br />
* If your battery fails in the meantime (and the image in your memory is therefore lost), you will be able to resumes from disk.<br />
<br />
This can be done both with uswsusp and with tuxonice. <br />
<br />
With uswsusp, you should use s2both. You can also call s2both from the hibernate script (with all its richness of options), resorting to the ususpend-both.conf method. Please note that s2both works only if s2ram (see [[Suspend to RAM]]) works in your system. There is no way to force it to work if your laptop model is not whitelisted in s2ram. See [[Suspend to RAM]] for instructions about how to whitelist your laptop in the local copy of s2ram and how to report that your laptop suspend to ram properly so that it is whitelisted in the next uswsusp release.<br />
<br />
To do it with tuxonice, edit ''/etc/hibernate/suspend2.conf'':<br />
<br />
## Powerdown method - 3 for suspend-to-RAM, 4 for ACPI S4 sleep, 5 for poweroff<br />
PowerdownMethod 3<br />
<br />
For this to work, your computer must be able to use suspend to RAM also without s2ram.</div>Cengichttps://wiki.archlinux.org/index.php?title=Hibernate-script&diff=36528Hibernate-script2008-02-03T00:35:27Z<p>Cengic: </p>
<hr />
<div>[[Category:Power management (English)]]<br />
[[Category:Laptops (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
This article will describe how to suspend a computer (usually a laptop) to disk. This means that all the running processes will be saved to the hard drive and power will completely shut down. This article discusses the two main maethods to accomplish this task, that is userspace suspension (uswsusp) and tuxonice (formerly known as suspend2). See the [http://suspend.sourceforge.net/ ususpend website] and the [http://www.tuxonice.net/ tuxonice website] for complete documentation. There is a third method: using the kernelspace functionalities of the vanilla kernel. However, this method is the least developed, the slowest and the less reliable. On the contrary, tuxonice and ususpend are competing in features and stability. The only method to decide which method is better for you is to try both of them. From a general point of view, we can say that uswsusp does not force you to patch, configure and compile a kernel, while tuxonice does. However, tuxonice can be used without an initrd/initramfs, while using ususpend without an initrd/initramfs is discouraged; moreover, tuxonice allows you to suspend on a regular file if you have not a swap partition, while uswsusp give this possibility only if you run an experimental and unstable mm kernel.<br />
<br />
It is important to distinguish the core method of suspension to disk from the userspace application which you use to hibernate your machine to disk. A userspace application is required because the large majority of the laptops require some quirks in order to accomplish a proficient, successful hibernation cycle: unloading modules, restarting services, unmount windows partitions and usb keys, and so on.<br />
<br />
There are two widely used userspace applications for this purpose: [[pm-utils]] and hibernate-script. You can find both of them in the extra repo. However, since in this guide we need to describe two different, competing core methods, we will focus on the hibernate-script, since only this script allows the user to choose the core method he prefers. On the contrary, [[pm-utils]], at least in the version actually distributed by arch, forces you silently to use the old vanilla method. On the other side, the script, developed by the tuxonice development team, can be used nonetheless also to hibernate your machine with the ususpend method, and even to suspend the machine to ram (actually it is an excellent tool also for this task, but we are not going to discuss this aspect in this document, see [[Suspend to RAM]]).<br />
<br />
If you prefer to use pm-utils, refer to the specific [[pm-utils|wiki article]].<br />
<br />
Thus:<br />
<br />
# pacman -S hibernate-script<br />
<br />
The discussion will be articulated in four parts. First of all, we will discuss the userspace method, secondly the tuxonice one, thirdly we will see how to use the power of the hibernate-script in order to circumvent some problems which could impair your ability to accomplish successful suspend/resume cycles. These last tips can be used with both methods. On the contrary, the first two parts will include instructions to use the hibernate-script in order to accomplish the basic operations with the two methods. In the fourth and last part, we will see how to combine suspension to disk and [[Suspend to RAM]] . <br />
<br />
When there is the need to modify the configuration of the bootloader, we will be always under the assumption that you use grub, but it should not be difficult to act analogously on the configuration of lilo.<br />
<br />
=Uswsusp method=<br />
<br />
The userspace method lets you resort to some advanced suspension abilities included in vanilla kernels > 2.6.17. You need two userspace tools, called s2disk and resume, which do what their names say. They are both included in the uswsusp package (which includes also s2ram, see [[Suspend to RAM]] ). You can find uswsusp in the AUR. The package in the AUR includes also an initramfs hook which allows you to resume properly using an initramfs.<br />
<br />
==Obtaining uswsusp==<br />
The first thing to do is to download the tarball from the AUR page. Compile the source and create the package with makepkg and install it with pacman -U.<br />
<br />
<br />
==Editing /etc/suspend.conf==<br />
On the contrary, you need to edit the s2disk configuration file, called /etc/suspend.conf. It is essential that you modify the resume device parameter:<br />
<br />
resume device = /dev/sda3<br />
<br />
It needs to point to your swap partition: in this case, the third partition of a primary pata-sata drive. It is also a good thing to enable compression, because this speeds up greatly your suspension/resume routine.<br />
<br />
Note that it is important that this configuration file be edited *before* recreating the initramfs (done below). Presently, the initramfs build process reads this configuration file, and embeds the current resume parameter. If not changed from the default '<path_to_resume_device_file>', this causes problems such as seeing, on bootup:<br />
<br />
# Could not stat the resume device file '<path_to_resume_device_file>'<br />
# Please type in the full path name to try again or press ENTER to boot the system.<br />
<br />
If you have experiencing this problem, simply edit the file as appropriate, and then rebuild the initramfs.<br />
<br />
==Recreate the intramfs==<br />
Now you need to recreate an initramfs with the new hook. So edit the /etc/mkinitcpio.conf file. In the HOOKS list add the uresume hook (it is different from the resume hook, which is on the contrary required by the tuxonice method). You should put it immediately before the filesystem hook. Now proceed to regenerate your initramfs :<br />
<br />
# mkinitcpio -k `uname -r` -g /boot/kernel26.img<br />
<br />
You need to adjust this command according to the kernel you plan to use and the name of the initramfs in the grub configuration. Anyway you should not need to modify anything in the grub configuration.<br />
<br />
==Support for encryption==<br />
The package in the AUR does already support encryption. You need to:<br />
* generate a key with the suspend-keygen utility included in the uswsusp package;<br />
* write the name of the key in /etc/suspend.conf;<br />
* uncomment or add the following line in /etc/suspend.conf<br />
<br />
encrypt=y<br />
* build a new initramfs with the uresume hook just before the filesystem one.<br />
<br />
==Support for splash screens and suspension to file==<br />
<br />
The AUR package does not provide support for splash screens: uswsusp would support splashy and fbsplash, but you need to modify the PKGBUILD in order to recompile uswsusp with libsplashy or fbsplash support: see the HOWTO and README in the source tarball for details.<br />
<br />
Please note that uswsusp can also suspend to a file, but only if you use an experimental mm-patched kernel. If you want to suspend to file, tuxonice is probably the way to go. In the case you like experimental things, see the instructions in the HOWTO of the uswsusp source tarball.<br />
<br />
==Suspending==<br />
<br />
Now you could try to suspend directly calling s2disk from the command line:<br />
<br />
# s2disk<br />
<br />
However, this is highly likely to fail, because some services could need to be stopped, some modules unloaded, etc. Thus it is probably necessary to resort to a userspace tool which calls internally s2disk. The hibernate-script does this. See [[Suspend to Disk#Editing /etc/hibernate/hibernate.conf|below]] about details for defining the ususpend-disk method as default in /etc/hibernate/hibernate.conf. For the moment being, remember that you can define specific options in /etc/hibernate/ususpend-disk.conf and, after having configured also /etc/hibernate/common.conf, you can suspend to disk with the uswsusp method with the following command:<br />
<br />
# hibernate -F /etc/hibernate/ususpend-disk.conf <br />
<br />
=Tuxonice method=<br />
<br />
==Obtaining tuxonice==<br />
Tuxonice consists of a kernel patch, plus a user interface. Only the kernel patch is necessary, the user interface provides merely a semi-graphical interface displayed during the hibernation/resume cycle. <br />
<br />
Archlinux used to deliver a binary tuxonice-patched kernel, but none of the devs want currently to maintain it. <br />
<br />
However you can use the kernel26tuxonice in AUR unsupported. It automatizes all the patch routine, the compilation and installation of the kernel, the regeneration of the initramfs with an appropriate hook. <br />
<br />
Otherwise, you need to patch, configure and compile your own kernel. You can do this either with the ABS method (starting from the arch default kernel PKGBUILD and adding the tuxonice patchset, or with the plain, old, reliable, venerable routine of <br />
<br />
# make menuconfig<br />
# make<br />
# make modules_install<br />
# cp arch/i386/boot/bzImage /boot/kernel-tuxonice-2.6.*<br />
<br />
See [[Kernel Compilation From Source]] and [[Kernel Compilation with ABS]] for instructions.<br />
In both cases, you need to configure the options added by the patchset, which you can find in the ACPI section of make menuconfig. Anyway, the defaults should be suitable for the large majority of scenarios. You can also hardcode in the kernel the path of your swap partition. In this case you can skip the below [[Suspend to Disk#Editing the Grub menu.lst]] .<br />
<br />
Please note that, if you spend the time to reconfigure completely the kernel (and in particular if you compile into the kernel the stuff necessary to boot your machine), you can be dispensed by the necessity to generate and use an initramfs: tuxonice will be able to resume properly also without an initrd/initramfs.<br />
<br />
==Editing the Grub menu.lst==<br />
Before your can use the suspend function, you need to boot your computer with the "resume" parameter, unless you have hardcoded your swap partition during the kernel configuration. The resume parameter points to the swap partition or swap file. The parameter is a kernel boot parameter, that is it should be added, if you use GRUB, to the line of /boot/grub/menu.lst where the location of your kernel is specified. <br />
For example:<br />
<br />
# tuxonice kernel<br />
title ArchLinux<br />
kernel /boot/kernel-tuxonice-2.6 root=/dev/hda2 resume=swap:/dev/hda3<br />
initrd /boot/tuxonice.img<br />
<br />
This assumes that you installed Archlinux onto the second hard drive partition, that your swap partition is the third, that you have not a separate /boot partition and that you are using an initrd. Adjust accordingly to your case.<br />
<br />
==Recreating the initramfs==<br />
<br />
If you use an initramfs, you need to add the tuxonice hook (which is different from the uresume used by uswsusp and by the resume hook for vanilla kernel suspension) in the HOOKS in the configuration of mkinitcpio. The hook is provided by the tuxoniceinitcpio package in AUR unsupported. This package is a dependency of kernel26tuxonice and is applied by default by kernel26tuxonice. Once you have added the tuxonice hook, you need to regenerate your initramfs, with a command like the following:<br />
<br />
# mkinitcpio -k kernel-tuxonice-2.6 -g /boot/tuxonice.img<br />
<br />
==Using userui - a user interface for tuxonice==<br />
<br />
Optionally, you can use a text or fbsplash interface with a progress bar with tuxonice. To do this, install the userui package in the extra repo:<br />
<br />
# pacman -S userui<br />
<br />
In ''/etc/hibernate/suspend2.conf'', configure the user interface:<br />
<br />
## Specify a userui like this:<br />
# text interface<br />
ProcSetting user_interface/program /usr/sbin/tuxoniceui_text<br />
<br />
or<br />
<br />
## Specify a userui like this:<br />
# fbsplash interface interface<br />
ProcSetting user_interface/program /usr/sbin/tuxoniceui_fbsplash<br />
<br />
The ''fbsplash'' interface also needs a fbsplash theme in ''/etc/splash/suspend2/''.<br />
<br />
The text interface may be good for debugging suspend2, as it displays some messages.<br />
You won't see a user interface for the first few seconds of the resume process unless you add the ''userui'' hook to your mkinitcpio configuration and regenerate your initramfs, but this is also optional.<br />
<br />
==Suspending and Resuming==<br />
<br />
Now you need to tweak the hibernate script. See [[Suspend to Disk#Editing /etc/hibernate/hibernate.conf|below]] for instructions about defining the tuxonice method as the default hibernation method. <br />
The specific file is /etc/hibernate/suspend2.conf (the hibernate-script still uses the old name of tuxonice):<br />
<br />
Make sure that the following lines are uncommented and appropriately configured:<br />
UseSuspend2 yes<br />
Reboot no<br />
EnableEscape yes<br />
DefaultConsoleLevel 1<br />
Compressor lzf<br />
<br />
Encryptor none<br />
<br />
Once you have tweaked what you want/need (also in /etc/hibernate/common.conf), you can try tuxonice hibernation with the following method:<br />
<br />
# hibernate -F /etc/hibernate/suspend2.conf<br />
<br />
You can abort a suspend cycle if you press the escape key. If you press a capital r, you will force the system to reboot after hibernation.<br />
If all goes well, you should be able to resume using the same Grub menu selection. If you make that option the default for Grub, you will always default to resuming if a resume image is available. '''Do never use a different kernel to resume than you used to suspend! If pacman updates your kernel, don't suspend before you have rebooted properly.''' It is recommended that you test the suspend/hibernate from a text console first and then once you have confirmed that it works try it from within X.<br />
<br />
You can make this practice safer adding the hibernate-cleanup service to your SERVICES array in /etc/rc.conf. This script will make sure that any stale image is deleted from your swap partition at boot time. This should make your system safe also in the case that you have chosen the mistaken kernel at the grub prompt. The hibernate-cleanup service is included in the hibernate-script package.<br />
<br />
== References ==<br />
<br />
*The [http://www.tuxonice.net tuxonice website] and the [http://wiki.tuxonice.net/ tuxonice wiki] are excellent sources of documentation.<br />
*There is a good [http://gentoo-wiki.com/HOWTO_Software_Suspend_v2 Gentoo wiki article] that covers a lot of the same material.<br />
<br />
<br />
=Hibernate tricks with the hibernate.script=<br />
<br />
This is a brief overview of the hibernate script. If you want to tweak it further, examine the ''common.conf'' and ''suspend2.conf'' files further and read the excellent and exhaustive man pages for hibernate and hibernate.conf.<br />
<br />
==Editing /etc/hibernate/hibernate.conf==<br />
<br />
In order to call directly the hibernate command without the -F option, you need to define your preferred hibernation method. This should be done in this file. If you list several methods, the first one will be used. Note that ''hibernate'' can also be used with [[Suspend to RAM]] or vanilla swsusp, but this is not part of this HOWTO).<br />
<br />
Then either:<br />
<br />
TryMethod ususpend-disk.conf<br />
<br />
or: <br />
<br />
TryMethod suspend2.conf<br />
<br />
==Editing /etc/hibernate/common.conf==<br />
<br />
The options in this file are used with any hibernation method (actually, the file is sourced by the configuration files of each method) and also by [[Suspend to RAM]] when accomplished with the hibernate-script. This file is complex and well commented. The man page hibernate.conf describes adequately all the options. Here, we can only stress the most commonly useful parts.<br />
<br />
Uncomment the lines for any filesystems that have the potential to change while your computer is suspended (for example shared partitions with windows like vfat or ntfs ones). They will be remounted upon resume. Otherwise you would risk corrupting the filesystems.<br />
<br />
### filesystems<br />
# Unmount /nfsshare /windows /mnt/sambaserver<br />
# UnmountFSTypes smbfs nfs<br />
# UnmountGraceTime 1<br />
# Mount /windows<br />
<br />
If you don't explicitly restore the volume levels, ALSA may have the sound channels muted after resuming. If this happens, look for<br />
<br />
### services<br />
<br />
in /etc/hibernate/common.conf and change the line just below to<br />
<br />
RestartServices alsa<br />
<br />
The alsa service will be stopped before suspension and restarted after resuming: the sound channels and volumes will be as before.<br />
You may want to restart other problematic services here.<br />
<br />
A common issue is that some drivers do not support suspension, that is they do not work properly after a suspension cycle or even they prevent the system from suspending or resuming properly. <br />
In these cases (which should be reported - at least for modules in the vanilla kernel - to the suspend-devel@lists.sourceforge.net mailing list, so that they can be fixed upstream) you can unload the module before suspension and reload it after resuming: the hibernate-script can automatize this routine with the LoadModules and UnloadModules options. Actually, the hibernate-script already unload some problematic modules, listed in /etc/hibernate/blacklisted-modules, so you can also add the modules in that file.<br />
<br />
If you need/want to eject all PcCards before suspending and reinsert them after resuming, change the ''EjectCards'' setting in ''common.conf'':<br />
<br />
### pcmcia<br />
EjectCards yes<br />
<br />
This is necessary on some laptops, if the pccards stop working after resume.<br />
<br />
Finally, the most problematic aspect is constituted by the video card: its status needs often to be restored after resuming. In other cases, it is necessary to switch from X to the console.<br />
The following options in /etc/hibernate/common.conf will probably fix these issues (whose symptom could be a frozen machine or only a black display after resuming):<br />
<br />
### vbetool<br />
#EnableVbetool yes<br />
#RestoreVbeStateFrom /var/lib/vbetool/vbestate<br />
#VbetoolPost yes<br />
# RestoreVCSAData yes<br />
<br />
### xhacks<br />
#SwitchToTextMode yes<br />
#UseDummyXServer yes<br />
#DummyXServerConfig xorg-dummy.conf<br />
<br />
You can uncomment one or many of them in order to see if the problem is solved. In order to use the first block of options, you need to install the vbetool package from the extra repository. Each of the option is documented in man hibernate.conf. <br />
Please note that it is very important to try all the different combinations of these options before than anything else, becaause the problems with the display are the most common source of troubles in a suspension cycle.<br />
<br />
== NVidia specific settings ==<br />
If you have an NVidia graphics card and are using the binary driver by NVidia with an AGP card, you have to add the following line to your /etc/X11/xorg.conf:<br />
<br />
Option "NvAGP" "1"<br />
<br />
NVidia also suggest this setting for the hibernate script:<br />
<br />
ProcSetting extra_pages_allowance 0<br />
<br />
to the file /etc/hibernate/common.conf. This setting also seems to help with the binary ATI driver. At last, you need to uncomment the nvidia module in /etc/hibernate/blacklisted-modules.<br />
<br />
== Suspending with fglrx ==<br />
Following addition to /etc/hibernate/suspend2.conf is required:<br />
<br />
# For fglrx<br />
ProcSetting extra_pages_allowance 20000<br />
<br />
== Dropping Disk Caches ==<br />
<br />
As a way to speed up suspending, you can free the memory used for disk caches. so there will be less to write to the disk. The downside is the risk of crashing your system. but I have had no trouble with it so far, while reducing the size of the suspended image by half. Just run this before hibernating:<br />
<br />
sync; echo 3 > /proc/sys/vm/drop_caches<br />
[http://www.linuxinsight.com/proc_sys_vm_drop_caches.html drop_caches introduction]<br />
<br />
=Combining suspend to disk with suspend to RAM=<br />
<br />
If your motherboard or laptop supports [[Suspend to RAM]], you can combine it with suspend2. This will result in the following behavior:<br />
<br />
* When you call hibernate, your system will suspend to disk and after that suspend to RAM instead of powering down.<br />
* When you turn your system back on, it will resume directly from RAM (which only takes a few seconds)<br />
* If your battery fails in the meantime (and the image in your memory is therefore lost), you will be able to resumes from disk.<br />
<br />
This can be done both with uswsusp and with tuxonice. <br />
<br />
With uswsusp, you should use s2both. You can also call s2both from the hibernate script (with all its richness of options), resorting to the ususepnd-both.conf method. Please note that s2both works only if s2ram (see [[Suspend to RAM]] works in your system. There is no way to force it to work if your laptop model is not whitelisted in s2ram. See [[Suspend to RAM]] for instructions about how to whitelist your laptop in the local copy of s2ram and how to report that your laptop suspend to ram properly so that it is whitelisted in the next uswsusp release.<br />
<br />
To do it with tuxonice, edit ''/etc/hibernate/suspend2.conf'':<br />
<br />
## Powerdown method - 3 for suspend-to-RAM, 4 for ACPI S4 sleep, 5 for poweroff<br />
PowerdownMethod 3<br />
<br />
For this to work, your computer must be able to use suspend to RAM also without s2ram.</div>Cengichttps://wiki.archlinux.org/index.php?title=User:Cengic&diff=36386User:Cengic2008-01-31T18:50:45Z<p>Cengic: </p>
<hr />
<div>Hi,<br />
<br />
My name is Goran Cengic and I'm a new Arch user switching from Slackware. I tried Arch several times before but it wasn't ready for me. Now when I'v tried it, it seems that it got a long way ahead. Nice clean init and easy text based confiuration for all major subsystems. I particularly like the use of the rc.conf and the design used for it. I also love the network profile system. I haven't seen anything as simple and useful in any other distro I have tried. And I have tried many :) <br />
<br />
I'v been using Linux since 1997 when I staretd out with Red Hat, moving on looking for the perfect distro until I found Slackware. I'v been Slack user for a decade now and I'm still using it on my desktop and workstation. The Arch is on my laptop since I'm spending more time on it nowdays.<br />
<br />
I'm looking forward to getting to know Arch better and being a part of the community.<br />
<br />
Regards.</div>Cengichttps://wiki.archlinux.org/index.php?title=Arch_terminology&diff=35642Arch terminology2008-01-26T15:59:26Z<p>Cengic: /* RTFM */</p>
<hr />
<div>[[Category:About Arch (English)]]<br />
[[Category:General (English)]]<br />
=Arch Terminology/Jargon for newbies=<br />
This page is intended to be a page to demystify common terms used among the Arch Linux community. Feel free to add or modify any terms, but please use that particular section's edit option. If you decide to add one, please put it in alphabetical order. <br />
<br />
==ABS==<br />
The Arch Build System (ABS for short) is useful to<br />
* Make new packages of software for which no packages are yet available<br />
* Customize/Modify existing packages to fit your needs (enabling or disabling options)<br />
* Re-build your entire system using your compiler flags, "a la Gentoo" (And getting kernel modules working with your custom kernel!) <br />
ABS is not necessary to use Arch Linux, but it is useful. <br />
<br />
For more information see the [[ABS]] page<br />
<br />
==AUR==<br />
The ArchLinux User-Community Repository (AUR) is a community driven repository for Arch users. The AUR was initially conceived to organize the sharing of PKGBUILDs amongst the wider community and to expedite the inclusion of popular user-contributed packages into the [core] and [extra] repos via the AUR [community] repo. <br />
<br />
It is called to be the birthplace of Arch's new packages. This is because in the AUR, the users contribute their own packages. The AUR community votes for or against them, and eventually, once a package has been voted high enough, a AUR Trusted User takes it to the [community] repository, which is accessible via pacman and ABS.<br />
<br />
You can access the ArchLinux User-Community Repository [http://aur.archlinux.org here]<br />
<br />
==PKGBUILD==<br />
[[ABS PKGBUILD Explained]]<br />
<br />
==TU==<br />
'''T'''rusted '''U'''ser. This is someone who the other TUs have voted into place to manage the AUR and the [community] repository.<br />
<br />
Trusted Users have the ability to mark a package as safe on the AUR, and if it has been voted as popular, move it into the [community] repository.<br />
<br />
Trusted users follow the [[AUR Trusted User Guidelines]] and [http://archlinux.org/~simo/TUbylaws.html TU by-laws]<br />
<br />
==TUR==<br />
'''T'''rusted '''U'''ser '''R'''epository (deprecated)<br />
Before AUR, TUs had their own repositories with (special versions of) applications that weren't available in the official ones. Anyone can make a repository, but TURs were thought to be of a higher quality, because TUs are voted for their knowledge and effort.<br />
<br />
==bbs==<br />
'''B'''ulletin '''B'''oard '''S'''ystem, but in Arch's case it's just the support forum located at http://bbs.archlinux.org.<br />
==community/[community]==<br />
The community repository is where pre-built packages are made available by Trusted Users. A majority of the packages in community, come from the AUR.<br />
<br />
To access the community repository, uncomment it in /etc/pacman.conf.<br />
<br />
==core/[core]==<br />
The Core repository contains the bare packages needed for an Arch System. It has everything needed to get a working command line system<br />
<br />
==custom/user repository==<br />
Anyone can create a repo and put it online so other users can use it. To create a repository, you need a set of packages and a pacman compatible database file for your packages. The DB file is created with [[Custom_local_repository_with_ABS_and_gensync|gensync]]. When you've got both, you can put them online (HTTP or FTP) and everyone will be able to use it by adding it as a regular repository.<br />
<br />
==developer==<br />
Half gods working to improve Arch for no financial gain. Developers are outranked only by our god, Judd Vinet.<br />
<br />
==devfs==<br />
The '''Dev'''ice '''F'''ile '''S'''ystem. DevFS handles, dynamically, the creation, deletion and permission management of device nodes in the /dev directory. It was the default kernel device manager in Arch Linux until release 0.7. Now DevFS is deprecated and in the process of being removed from the Linux kernel. DevFS has been superseded by [[udev]].<br />
<br />
Note that Arch installation CDs prior to 0.7.1 use the devfs naming scheme when creating /etc/fstab entries. See [[DevFS to Udev]].<br />
<br />
==/etc/network-profiles==<br />
In this, you can create various network configurations.<br />
<br />
This is very useful for laptop users that switch networks very often, for example between a home and an office network.<br />
<br />
Additionally it can be used with wpa-supplicant that can manage all of you wireless networks.<br />
For each configuration you need to make a configuration file. The easiest way to do this, is by copying the template.<br />
After you are done with this, you need to enable these in /etc/rc.conf<br />
<br />
After applying changes, you should restart your network by using, as root,<br />
/etc/rc.d/network restart<br />
<br />
==/etc/rc.conf==<br />
/etc/rc.conf is the main system configuration file for Arch Linux. It allows you to set your keyboard, timezone, hostname, network, daemons to run and modules to load at bootup, profiles, and more. Detailed description of the configuration options is given here: [[Rc.conf]]<br />
<br />
==/etc/rc.d==<br />
/etc/rc.d is a directory that contains the scripts that handle starting and stopping of services. On every boot, the services that are present in the DAEMONS= array in /etc/rc.conf are started by running the corresponding scripts in /etc/rc.d.<br />
<br />
It is also possible to control the services from the command line (as root), e.g.,<br />
<br />
/etc/rc.d/cups start<br />
<br />
would start the CUPS daemon. Typical arguments for the scripts are start, stop and restart.<br />
<br />
==/etc/rc.local==<br />
This script is run at the end of every boot. It is intended for miscellaneous commands that you might want to execute before the login prompt. It is not recommended to add any services or settings in /etc/rc.local that could be started or set from /etc/rc.conf instead.<br />
<br />
==extra/[extra]==<br />
Arch's official package set is fairly streamlined, but we supplement this with a larger, more complete "extra" repository that contains a lot of the stuff that never made it into our core package set. This repository is constantly growing with the help of packages submitted from our strong community.<br />
This is where desktop environments, window managers and common programs are found.<br />
<br />
==hotplug==<br />
==hwd==<br />
Hwd; hardware detect for Arch Linux, is for both devfs and udev device systems and also for kernels 2.4.x and 2.6.x. Instead of running an auto configure script what may be expected, Hwd (/usr/bin/hwd) doesn't change existing configures. Detects hardwares and modules, and provides information how to do manually. This allows the user to have a control over his/her system; basic philosophy of Arch Linux.<br />
<br />
Hwd is uploaded in Arch Linux's extra repository. To install, run pacman. <br />
<br />
pacman -S hwd<br />
<br />
here can you see the things you can use Hwd to [http://amlug.net/new-projects/hwd/hwd-46.jpg]<br />
<br />
==hwdetect==<br />
==initramfs==<br />
==initrd==<br />
The special file /dev/initrd is a read-only block device. Device /dev/initrd is a RAM disk that is initialized (e.g. loaded) by the boot loader before the kernel is started. The kernel then can use the block device /dev/initrd's contents for a two phased system boot-up.<br />
<br />
In the first boot-up phase, the kernel starts up and mounts an initial root file-system from the contents of /dev/initrd (e.g. RAM disk initialized by the boot loader). In the second phase, additional drivers or other modules are loaded from the initial root device's contents. After loading the additional modules, a new root file system (i.e. the normal root file system) is mounted from a different device.<br />
<br />
==makepkg==<br />
makepkg will build packages for you. makepkg will read the metadata required from a PKGBUILD file.<br />
All it needs is a build-capable linux platform, wget, and some build scripts. The advantage to a script-based build is that you only really do the work once. Once you have the build script for a package, you just need to run makepkg and it will do the rest: download and validate source files, check dependencies, configure the build time settings, build the package, install the package into a temporary root, make customizations, generate meta-info, and package the whole thing up for pacman to use.<br />
<br />
==namcap==<br />
namcap is a package analysis utility that looks for problems with ArchLinux packages or their PKGBUILD files. It can apply rules to the file list, the files themselves, or individual PKGBUILD files.<br />
<br />
Rules return lists of messages. Each message can be one of three types: error, warning, or information (think of them as notes or comments). Errors (designated by 'E:') are things that namcap is very sure are wrong and need to be fixed. Warnings (designated by 'W:') are things that namcap thinks should be changed but if you know what you're doing then you can leave them. Information (designated 'I:') are only shown when you use the info argument. Information messages give information that might be helpful but isn't anything that needs changing.<br />
<br />
==package==<br />
A package is an archive containing<br />
* all the (compiled) files of an application<br />
* metadata about the application, such as application name, version, dependencies, ...<br />
* installation files and directives for pacman<br />
* (optionally) extra files to make your life easier, such as a start/stop script<br />
Arch's package manager pacman can install, update and remove programs cleanly those packages. Using packages instead of compiling and installing programs yourself has various benefits:<br />
* easily updatable: pacman will update existing packages as soon as updates are available<br />
* dependency checks: pacman handles dependencies for you, you only need to specify the program and pacman installs it together with every other program it needs<br />
* clean removal: pacman has a list of every file in a package. This way no files are left behind when you decide to remove a package<br />
Note: different GNU/Linux distributions use different packages and package manager, meaning that you can't use pacman to install a Debian package on Arch.<br />
<br />
==pacman==<br />
The [[Pacman]] package manager is one of the great highlights of Arch Linux. It combines a simple binary package format with an easy-to-use build system (see ABS). Pacman makes it possible to easily manage and customize packages, whether they be from the official Arch repositories or the user's own creations. The repository system allows users to build and maintain their own custom package repositories, which encourages community growth and contribution (see AUR). <br />
<br />
Pacman can keep a system up to date by synchronizing package lists with the master server, making it a breeze for the security-conscious system administrator to maintain. This server/client model also allows you to download/install packages with a simple command, complete with all required dependencies (similar to Debian's apt-get). <br />
<br />
NB: Pacman was written and is being maintained by Judd Vinet, the creator of Arch Linux. It is used as a package management tool by other distros as well, such as FrugalWare (see also [[1]]), Rubix, UfficioZero (in Italian, based on Ubuntu), and, of course, ArchLinux-derivatives such as Archie and AEGIS.<br />
<br />
==pacman.conf==<br />
This is the configuration file of pacman. It's located in /etc. For a full explanation of its powers<br />
man pacman.conf<br />
<br />
==release/[release]==<br />
Release repository follows the semi-regular snapshot releases and does not update until the next snapshot/iso has been released. For example, the Release repository will point to all packages on the 0.5 ISO until we release 0.6; then it will point to 0.6 packages until 0.7 is released. This is useful if you only want to update your system when a new release is available.<br />
<br />
==repository/repo==<br />
The repository has the pre-compiled packages of one or (usually) more PKGBUILDs. Official repositories are<br />
* core: containing the latest version of packages required for a full CLI system<br />
* extra: containing the latest version of packages not needed for a working system, but needed for an enjoyable system ;)<br />
* community: containing packages that came from [http://aur.archlinux.org AUR] and got enough user votes<br />
Pacman uses these repositories to search for packages and install them. A repository can be local (i.e. on your own computer) or remote (i.e. the packages are downloaded before they're installed).<br />
<br />
==RTFM==<br />
'''R'''ead '''T'''he '''F'''ucking '''M'''anual. This simple message is replied to a lot of new linux/arch users who ask about the functionality of a program, when it is clearly defined in the program's manual.<br />
<br />
It is often used when a user fails to make any attempt to find a solution to the problem themselves. If someone tells you this, they are not trying to offend you, they are just frustrated with your lack of effort. <br />
<br />
The best thing to do if you are told to do this is to read the manual page.<br />
* To read the program manual page at the command line type:<br />
man <program-name><br />
<br />
If you do not find the answer to your question in the program manual there are more ways to find the answer.You can:<br />
* search the [[Main Page | wiki]]<br />
* search the [http://bbs.archlinux.org forum]<br />
* search the [http://www.google.com web]<br />
<br />
==testing/[testing]==<br />
This is the repo where major packages/updates to packages are kept prior to release into the main repos, so they can be bug tested and upgrade issues can be found. It is disabled by default, but can be enabled in <code>/etc/pacman.conf</code><br />
<br />
==udev==<br />
udev provides a dynamic device directory containing only the files for actually present devices. It creates or removes device node files in the /dev directory, or it renames network interfaces.<br />
<br />
Usually udev runs as udevd(8) and receives uevents directly from the kernel if a device is added or removed form the system.<br />
<br />
If udev receives a device event, it matches its configured rules against the available device attributes provided in sysfs to identify the device. Rules that match, may provide additional device information or specify a device node name and multiple symlink names and instruct udev to run additional programs as part of the device event handling.<br />
<br />
==unstable/[unstable]==<br />
==versionpkg==<br />
This is a very simple script that allows you to easily update your CVS and SVN packages without having to edit the PKGBUILDs manually to enter the date or revision number. <br />
<br />
Simply run this script rather than makepkg in the build dir. This script completely removes the need for backtick execution to set the date or tag version in PKGBUILDs.<br />
<br />
More detailed information can be found [[Arch_CVS_%26_SVN_PKGBUILD_guidelines#versionpkg_-_a_makepkg_wrapper_for_CVS.2FSVN_builds|here]].<br />
<br />
==wiki==<br />
[[Main Page|This!]] A place to find documentation about ArchLinux. Anyone can add and modify the documentation.</div>Cengichttps://wiki.archlinux.org/index.php?title=Arch_terminology&diff=35641Arch terminology2008-01-26T15:58:55Z<p>Cengic: /* RTFM */</p>
<hr />
<div>[[Category:About Arch (English)]]<br />
[[Category:General (English)]]<br />
=Arch Terminology/Jargon for newbies=<br />
This page is intended to be a page to demystify common terms used among the Arch Linux community. Feel free to add or modify any terms, but please use that particular section's edit option. If you decide to add one, please put it in alphabetical order. <br />
<br />
==ABS==<br />
The Arch Build System (ABS for short) is useful to<br />
* Make new packages of software for which no packages are yet available<br />
* Customize/Modify existing packages to fit your needs (enabling or disabling options)<br />
* Re-build your entire system using your compiler flags, "a la Gentoo" (And getting kernel modules working with your custom kernel!) <br />
ABS is not necessary to use Arch Linux, but it is useful. <br />
<br />
For more information see the [[ABS]] page<br />
<br />
==AUR==<br />
The ArchLinux User-Community Repository (AUR) is a community driven repository for Arch users. The AUR was initially conceived to organize the sharing of PKGBUILDs amongst the wider community and to expedite the inclusion of popular user-contributed packages into the [core] and [extra] repos via the AUR [community] repo. <br />
<br />
It is called to be the birthplace of Arch's new packages. This is because in the AUR, the users contribute their own packages. The AUR community votes for or against them, and eventually, once a package has been voted high enough, a AUR Trusted User takes it to the [community] repository, which is accessible via pacman and ABS.<br />
<br />
You can access the ArchLinux User-Community Repository [http://aur.archlinux.org here]<br />
<br />
==PKGBUILD==<br />
[[ABS PKGBUILD Explained]]<br />
<br />
==TU==<br />
'''T'''rusted '''U'''ser. This is someone who the other TUs have voted into place to manage the AUR and the [community] repository.<br />
<br />
Trusted Users have the ability to mark a package as safe on the AUR, and if it has been voted as popular, move it into the [community] repository.<br />
<br />
Trusted users follow the [[AUR Trusted User Guidelines]] and [http://archlinux.org/~simo/TUbylaws.html TU by-laws]<br />
<br />
==TUR==<br />
'''T'''rusted '''U'''ser '''R'''epository (deprecated)<br />
Before AUR, TUs had their own repositories with (special versions of) applications that weren't available in the official ones. Anyone can make a repository, but TURs were thought to be of a higher quality, because TUs are voted for their knowledge and effort.<br />
<br />
==bbs==<br />
'''B'''ulletin '''B'''oard '''S'''ystem, but in Arch's case it's just the support forum located at http://bbs.archlinux.org.<br />
==community/[community]==<br />
The community repository is where pre-built packages are made available by Trusted Users. A majority of the packages in community, come from the AUR.<br />
<br />
To access the community repository, uncomment it in /etc/pacman.conf.<br />
<br />
==core/[core]==<br />
The Core repository contains the bare packages needed for an Arch System. It has everything needed to get a working command line system<br />
<br />
==custom/user repository==<br />
Anyone can create a repo and put it online so other users can use it. To create a repository, you need a set of packages and a pacman compatible database file for your packages. The DB file is created with [[Custom_local_repository_with_ABS_and_gensync|gensync]]. When you've got both, you can put them online (HTTP or FTP) and everyone will be able to use it by adding it as a regular repository.<br />
<br />
==developer==<br />
Half gods working to improve Arch for no financial gain. Developers are outranked only by our god, Judd Vinet.<br />
<br />
==devfs==<br />
The '''Dev'''ice '''F'''ile '''S'''ystem. DevFS handles, dynamically, the creation, deletion and permission management of device nodes in the /dev directory. It was the default kernel device manager in Arch Linux until release 0.7. Now DevFS is deprecated and in the process of being removed from the Linux kernel. DevFS has been superseded by [[udev]].<br />
<br />
Note that Arch installation CDs prior to 0.7.1 use the devfs naming scheme when creating /etc/fstab entries. See [[DevFS to Udev]].<br />
<br />
==/etc/network-profiles==<br />
In this, you can create various network configurations.<br />
<br />
This is very useful for laptop users that switch networks very often, for example between a home and an office network.<br />
<br />
Additionally it can be used with wpa-supplicant that can manage all of you wireless networks.<br />
For each configuration you need to make a configuration file. The easiest way to do this, is by copying the template.<br />
After you are done with this, you need to enable these in /etc/rc.conf<br />
<br />
After applying changes, you should restart your network by using, as root,<br />
/etc/rc.d/network restart<br />
<br />
==/etc/rc.conf==<br />
/etc/rc.conf is the main system configuration file for Arch Linux. It allows you to set your keyboard, timezone, hostname, network, daemons to run and modules to load at bootup, profiles, and more. Detailed description of the configuration options is given here: [[Rc.conf]]<br />
<br />
==/etc/rc.d==<br />
/etc/rc.d is a directory that contains the scripts that handle starting and stopping of services. On every boot, the services that are present in the DAEMONS= array in /etc/rc.conf are started by running the corresponding scripts in /etc/rc.d.<br />
<br />
It is also possible to control the services from the command line (as root), e.g.,<br />
<br />
/etc/rc.d/cups start<br />
<br />
would start the CUPS daemon. Typical arguments for the scripts are start, stop and restart.<br />
<br />
==/etc/rc.local==<br />
This script is run at the end of every boot. It is intended for miscellaneous commands that you might want to execute before the login prompt. It is not recommended to add any services or settings in /etc/rc.local that could be started or set from /etc/rc.conf instead.<br />
<br />
==extra/[extra]==<br />
Arch's official package set is fairly streamlined, but we supplement this with a larger, more complete "extra" repository that contains a lot of the stuff that never made it into our core package set. This repository is constantly growing with the help of packages submitted from our strong community.<br />
This is where desktop environments, window managers and common programs are found.<br />
<br />
==hotplug==<br />
==hwd==<br />
Hwd; hardware detect for Arch Linux, is for both devfs and udev device systems and also for kernels 2.4.x and 2.6.x. Instead of running an auto configure script what may be expected, Hwd (/usr/bin/hwd) doesn't change existing configures. Detects hardwares and modules, and provides information how to do manually. This allows the user to have a control over his/her system; basic philosophy of Arch Linux.<br />
<br />
Hwd is uploaded in Arch Linux's extra repository. To install, run pacman. <br />
<br />
pacman -S hwd<br />
<br />
here can you see the things you can use Hwd to [http://amlug.net/new-projects/hwd/hwd-46.jpg]<br />
<br />
==hwdetect==<br />
==initramfs==<br />
==initrd==<br />
The special file /dev/initrd is a read-only block device. Device /dev/initrd is a RAM disk that is initialized (e.g. loaded) by the boot loader before the kernel is started. The kernel then can use the block device /dev/initrd's contents for a two phased system boot-up.<br />
<br />
In the first boot-up phase, the kernel starts up and mounts an initial root file-system from the contents of /dev/initrd (e.g. RAM disk initialized by the boot loader). In the second phase, additional drivers or other modules are loaded from the initial root device's contents. After loading the additional modules, a new root file system (i.e. the normal root file system) is mounted from a different device.<br />
<br />
==makepkg==<br />
makepkg will build packages for you. makepkg will read the metadata required from a PKGBUILD file.<br />
All it needs is a build-capable linux platform, wget, and some build scripts. The advantage to a script-based build is that you only really do the work once. Once you have the build script for a package, you just need to run makepkg and it will do the rest: download and validate source files, check dependencies, configure the build time settings, build the package, install the package into a temporary root, make customizations, generate meta-info, and package the whole thing up for pacman to use.<br />
<br />
==namcap==<br />
namcap is a package analysis utility that looks for problems with ArchLinux packages or their PKGBUILD files. It can apply rules to the file list, the files themselves, or individual PKGBUILD files.<br />
<br />
Rules return lists of messages. Each message can be one of three types: error, warning, or information (think of them as notes or comments). Errors (designated by 'E:') are things that namcap is very sure are wrong and need to be fixed. Warnings (designated by 'W:') are things that namcap thinks should be changed but if you know what you're doing then you can leave them. Information (designated 'I:') are only shown when you use the info argument. Information messages give information that might be helpful but isn't anything that needs changing.<br />
<br />
==package==<br />
A package is an archive containing<br />
* all the (compiled) files of an application<br />
* metadata about the application, such as application name, version, dependencies, ...<br />
* installation files and directives for pacman<br />
* (optionally) extra files to make your life easier, such as a start/stop script<br />
Arch's package manager pacman can install, update and remove programs cleanly those packages. Using packages instead of compiling and installing programs yourself has various benefits:<br />
* easily updatable: pacman will update existing packages as soon as updates are available<br />
* dependency checks: pacman handles dependencies for you, you only need to specify the program and pacman installs it together with every other program it needs<br />
* clean removal: pacman has a list of every file in a package. This way no files are left behind when you decide to remove a package<br />
Note: different GNU/Linux distributions use different packages and package manager, meaning that you can't use pacman to install a Debian package on Arch.<br />
<br />
==pacman==<br />
The [[Pacman]] package manager is one of the great highlights of Arch Linux. It combines a simple binary package format with an easy-to-use build system (see ABS). Pacman makes it possible to easily manage and customize packages, whether they be from the official Arch repositories or the user's own creations. The repository system allows users to build and maintain their own custom package repositories, which encourages community growth and contribution (see AUR). <br />
<br />
Pacman can keep a system up to date by synchronizing package lists with the master server, making it a breeze for the security-conscious system administrator to maintain. This server/client model also allows you to download/install packages with a simple command, complete with all required dependencies (similar to Debian's apt-get). <br />
<br />
NB: Pacman was written and is being maintained by Judd Vinet, the creator of Arch Linux. It is used as a package management tool by other distros as well, such as FrugalWare (see also [[1]]), Rubix, UfficioZero (in Italian, based on Ubuntu), and, of course, ArchLinux-derivatives such as Archie and AEGIS.<br />
<br />
==pacman.conf==<br />
This is the configuration file of pacman. It's located in /etc. For a full explanation of its powers<br />
man pacman.conf<br />
<br />
==release/[release]==<br />
Release repository follows the semi-regular snapshot releases and does not update until the next snapshot/iso has been released. For example, the Release repository will point to all packages on the 0.5 ISO until we release 0.6; then it will point to 0.6 packages until 0.7 is released. This is useful if you only want to update your system when a new release is available.<br />
<br />
==repository/repo==<br />
The repository has the pre-compiled packages of one or (usually) more PKGBUILDs. Official repositories are<br />
* core: containing the latest version of packages required for a full CLI system<br />
* extra: containing the latest version of packages not needed for a working system, but needed for an enjoyable system ;)<br />
* community: containing packages that came from [http://aur.archlinux.org AUR] and got enough user votes<br />
Pacman uses these repositories to search for packages and install them. A repository can be local (i.e. on your own computer) or remote (i.e. the packages are downloaded before they're installed).<br />
<br />
==RTFM==<br />
'''R'''ead '''T'''he '''F'''ucking '''M'''anual. This simple message is replied to a lot of new linux/arch users who ask about the functionality of a program, when it is clearly defined in the program's manual.<br />
<br />
It is often used when a user fails to make any attempt to find a solution to the problem themselves. If someone tells you this, they are not trying to offend you, they are just frustrated with your lack of effort. <br />
<br />
The best thing to do if you are told to do this is to read the manual page.<br />
* To read the program manual page at the command line type:<br />
man <program-name><br />
<br />
If you do not find the answer to your question in the program manual there are more ways to find the answer.You can:<br />
* search the [[Main Page | wiki]]<br />
* search the [http://bbs.archlinux.org/ forum]<br />
* search the web<br />
<br />
==testing/[testing]==<br />
This is the repo where major packages/updates to packages are kept prior to release into the main repos, so they can be bug tested and upgrade issues can be found. It is disabled by default, but can be enabled in <code>/etc/pacman.conf</code><br />
<br />
==udev==<br />
udev provides a dynamic device directory containing only the files for actually present devices. It creates or removes device node files in the /dev directory, or it renames network interfaces.<br />
<br />
Usually udev runs as udevd(8) and receives uevents directly from the kernel if a device is added or removed form the system.<br />
<br />
If udev receives a device event, it matches its configured rules against the available device attributes provided in sysfs to identify the device. Rules that match, may provide additional device information or specify a device node name and multiple symlink names and instruct udev to run additional programs as part of the device event handling.<br />
<br />
==unstable/[unstable]==<br />
==versionpkg==<br />
This is a very simple script that allows you to easily update your CVS and SVN packages without having to edit the PKGBUILDs manually to enter the date or revision number. <br />
<br />
Simply run this script rather than makepkg in the build dir. This script completely removes the need for backtick execution to set the date or tag version in PKGBUILDs.<br />
<br />
More detailed information can be found [[Arch_CVS_%26_SVN_PKGBUILD_guidelines#versionpkg_-_a_makepkg_wrapper_for_CVS.2FSVN_builds|here]].<br />
<br />
==wiki==<br />
[[Main Page|This!]] A place to find documentation about ArchLinux. Anyone can add and modify the documentation.</div>Cengichttps://wiki.archlinux.org/index.php?title=Arch_terminology&diff=35640Arch terminology2008-01-26T15:58:06Z<p>Cengic: /* RTFM */</p>
<hr />
<div>[[Category:About Arch (English)]]<br />
[[Category:General (English)]]<br />
=Arch Terminology/Jargon for newbies=<br />
This page is intended to be a page to demystify common terms used among the Arch Linux community. Feel free to add or modify any terms, but please use that particular section's edit option. If you decide to add one, please put it in alphabetical order. <br />
<br />
==ABS==<br />
The Arch Build System (ABS for short) is useful to<br />
* Make new packages of software for which no packages are yet available<br />
* Customize/Modify existing packages to fit your needs (enabling or disabling options)<br />
* Re-build your entire system using your compiler flags, "a la Gentoo" (And getting kernel modules working with your custom kernel!) <br />
ABS is not necessary to use Arch Linux, but it is useful. <br />
<br />
For more information see the [[ABS]] page<br />
<br />
==AUR==<br />
The ArchLinux User-Community Repository (AUR) is a community driven repository for Arch users. The AUR was initially conceived to organize the sharing of PKGBUILDs amongst the wider community and to expedite the inclusion of popular user-contributed packages into the [core] and [extra] repos via the AUR [community] repo. <br />
<br />
It is called to be the birthplace of Arch's new packages. This is because in the AUR, the users contribute their own packages. The AUR community votes for or against them, and eventually, once a package has been voted high enough, a AUR Trusted User takes it to the [community] repository, which is accessible via pacman and ABS.<br />
<br />
You can access the ArchLinux User-Community Repository [http://aur.archlinux.org here]<br />
<br />
==PKGBUILD==<br />
[[ABS PKGBUILD Explained]]<br />
<br />
==TU==<br />
'''T'''rusted '''U'''ser. This is someone who the other TUs have voted into place to manage the AUR and the [community] repository.<br />
<br />
Trusted Users have the ability to mark a package as safe on the AUR, and if it has been voted as popular, move it into the [community] repository.<br />
<br />
Trusted users follow the [[AUR Trusted User Guidelines]] and [http://archlinux.org/~simo/TUbylaws.html TU by-laws]<br />
<br />
==TUR==<br />
'''T'''rusted '''U'''ser '''R'''epository (deprecated)<br />
Before AUR, TUs had their own repositories with (special versions of) applications that weren't available in the official ones. Anyone can make a repository, but TURs were thought to be of a higher quality, because TUs are voted for their knowledge and effort.<br />
<br />
==bbs==<br />
'''B'''ulletin '''B'''oard '''S'''ystem, but in Arch's case it's just the support forum located at http://bbs.archlinux.org.<br />
==community/[community]==<br />
The community repository is where pre-built packages are made available by Trusted Users. A majority of the packages in community, come from the AUR.<br />
<br />
To access the community repository, uncomment it in /etc/pacman.conf.<br />
<br />
==core/[core]==<br />
The Core repository contains the bare packages needed for an Arch System. It has everything needed to get a working command line system<br />
<br />
==custom/user repository==<br />
Anyone can create a repo and put it online so other users can use it. To create a repository, you need a set of packages and a pacman compatible database file for your packages. The DB file is created with [[Custom_local_repository_with_ABS_and_gensync|gensync]]. When you've got both, you can put them online (HTTP or FTP) and everyone will be able to use it by adding it as a regular repository.<br />
<br />
==developer==<br />
Half gods working to improve Arch for no financial gain. Developers are outranked only by our god, Judd Vinet.<br />
<br />
==devfs==<br />
The '''Dev'''ice '''F'''ile '''S'''ystem. DevFS handles, dynamically, the creation, deletion and permission management of device nodes in the /dev directory. It was the default kernel device manager in Arch Linux until release 0.7. Now DevFS is deprecated and in the process of being removed from the Linux kernel. DevFS has been superseded by [[udev]].<br />
<br />
Note that Arch installation CDs prior to 0.7.1 use the devfs naming scheme when creating /etc/fstab entries. See [[DevFS to Udev]].<br />
<br />
==/etc/network-profiles==<br />
In this, you can create various network configurations.<br />
<br />
This is very useful for laptop users that switch networks very often, for example between a home and an office network.<br />
<br />
Additionally it can be used with wpa-supplicant that can manage all of you wireless networks.<br />
For each configuration you need to make a configuration file. The easiest way to do this, is by copying the template.<br />
After you are done with this, you need to enable these in /etc/rc.conf<br />
<br />
After applying changes, you should restart your network by using, as root,<br />
/etc/rc.d/network restart<br />
<br />
==/etc/rc.conf==<br />
/etc/rc.conf is the main system configuration file for Arch Linux. It allows you to set your keyboard, timezone, hostname, network, daemons to run and modules to load at bootup, profiles, and more. Detailed description of the configuration options is given here: [[Rc.conf]]<br />
<br />
==/etc/rc.d==<br />
/etc/rc.d is a directory that contains the scripts that handle starting and stopping of services. On every boot, the services that are present in the DAEMONS= array in /etc/rc.conf are started by running the corresponding scripts in /etc/rc.d.<br />
<br />
It is also possible to control the services from the command line (as root), e.g.,<br />
<br />
/etc/rc.d/cups start<br />
<br />
would start the CUPS daemon. Typical arguments for the scripts are start, stop and restart.<br />
<br />
==/etc/rc.local==<br />
This script is run at the end of every boot. It is intended for miscellaneous commands that you might want to execute before the login prompt. It is not recommended to add any services or settings in /etc/rc.local that could be started or set from /etc/rc.conf instead.<br />
<br />
==extra/[extra]==<br />
Arch's official package set is fairly streamlined, but we supplement this with a larger, more complete "extra" repository that contains a lot of the stuff that never made it into our core package set. This repository is constantly growing with the help of packages submitted from our strong community.<br />
This is where desktop environments, window managers and common programs are found.<br />
<br />
==hotplug==<br />
==hwd==<br />
Hwd; hardware detect for Arch Linux, is for both devfs and udev device systems and also for kernels 2.4.x and 2.6.x. Instead of running an auto configure script what may be expected, Hwd (/usr/bin/hwd) doesn't change existing configures. Detects hardwares and modules, and provides information how to do manually. This allows the user to have a control over his/her system; basic philosophy of Arch Linux.<br />
<br />
Hwd is uploaded in Arch Linux's extra repository. To install, run pacman. <br />
<br />
pacman -S hwd<br />
<br />
here can you see the things you can use Hwd to [http://amlug.net/new-projects/hwd/hwd-46.jpg]<br />
<br />
==hwdetect==<br />
==initramfs==<br />
==initrd==<br />
The special file /dev/initrd is a read-only block device. Device /dev/initrd is a RAM disk that is initialized (e.g. loaded) by the boot loader before the kernel is started. The kernel then can use the block device /dev/initrd's contents for a two phased system boot-up.<br />
<br />
In the first boot-up phase, the kernel starts up and mounts an initial root file-system from the contents of /dev/initrd (e.g. RAM disk initialized by the boot loader). In the second phase, additional drivers or other modules are loaded from the initial root device's contents. After loading the additional modules, a new root file system (i.e. the normal root file system) is mounted from a different device.<br />
<br />
==makepkg==<br />
makepkg will build packages for you. makepkg will read the metadata required from a PKGBUILD file.<br />
All it needs is a build-capable linux platform, wget, and some build scripts. The advantage to a script-based build is that you only really do the work once. Once you have the build script for a package, you just need to run makepkg and it will do the rest: download and validate source files, check dependencies, configure the build time settings, build the package, install the package into a temporary root, make customizations, generate meta-info, and package the whole thing up for pacman to use.<br />
<br />
==namcap==<br />
namcap is a package analysis utility that looks for problems with ArchLinux packages or their PKGBUILD files. It can apply rules to the file list, the files themselves, or individual PKGBUILD files.<br />
<br />
Rules return lists of messages. Each message can be one of three types: error, warning, or information (think of them as notes or comments). Errors (designated by 'E:') are things that namcap is very sure are wrong and need to be fixed. Warnings (designated by 'W:') are things that namcap thinks should be changed but if you know what you're doing then you can leave them. Information (designated 'I:') are only shown when you use the info argument. Information messages give information that might be helpful but isn't anything that needs changing.<br />
<br />
==package==<br />
A package is an archive containing<br />
* all the (compiled) files of an application<br />
* metadata about the application, such as application name, version, dependencies, ...<br />
* installation files and directives for pacman<br />
* (optionally) extra files to make your life easier, such as a start/stop script<br />
Arch's package manager pacman can install, update and remove programs cleanly those packages. Using packages instead of compiling and installing programs yourself has various benefits:<br />
* easily updatable: pacman will update existing packages as soon as updates are available<br />
* dependency checks: pacman handles dependencies for you, you only need to specify the program and pacman installs it together with every other program it needs<br />
* clean removal: pacman has a list of every file in a package. This way no files are left behind when you decide to remove a package<br />
Note: different GNU/Linux distributions use different packages and package manager, meaning that you can't use pacman to install a Debian package on Arch.<br />
<br />
==pacman==<br />
The [[Pacman]] package manager is one of the great highlights of Arch Linux. It combines a simple binary package format with an easy-to-use build system (see ABS). Pacman makes it possible to easily manage and customize packages, whether they be from the official Arch repositories or the user's own creations. The repository system allows users to build and maintain their own custom package repositories, which encourages community growth and contribution (see AUR). <br />
<br />
Pacman can keep a system up to date by synchronizing package lists with the master server, making it a breeze for the security-conscious system administrator to maintain. This server/client model also allows you to download/install packages with a simple command, complete with all required dependencies (similar to Debian's apt-get). <br />
<br />
NB: Pacman was written and is being maintained by Judd Vinet, the creator of Arch Linux. It is used as a package management tool by other distros as well, such as FrugalWare (see also [[1]]), Rubix, UfficioZero (in Italian, based on Ubuntu), and, of course, ArchLinux-derivatives such as Archie and AEGIS.<br />
<br />
==pacman.conf==<br />
This is the configuration file of pacman. It's located in /etc. For a full explanation of its powers<br />
man pacman.conf<br />
<br />
==release/[release]==<br />
Release repository follows the semi-regular snapshot releases and does not update until the next snapshot/iso has been released. For example, the Release repository will point to all packages on the 0.5 ISO until we release 0.6; then it will point to 0.6 packages until 0.7 is released. This is useful if you only want to update your system when a new release is available.<br />
<br />
==repository/repo==<br />
The repository has the pre-compiled packages of one or (usually) more PKGBUILDs. Official repositories are<br />
* core: containing the latest version of packages required for a full CLI system<br />
* extra: containing the latest version of packages not needed for a working system, but needed for an enjoyable system ;)<br />
* community: containing packages that came from [http://aur.archlinux.org AUR] and got enough user votes<br />
Pacman uses these repositories to search for packages and install them. A repository can be local (i.e. on your own computer) or remote (i.e. the packages are downloaded before they're installed).<br />
<br />
==RTFM==<br />
'''R'''ead '''T'''he '''F'''ucking '''M'''anual. This simple message is replied to a lot of new linux/arch users who ask about the functionality of a program, when it is clearly defined in the program's manual.<br />
<br />
It is often used when a user fails to make any attempt to find a solution to the problem themselves. If someone tells you this, they are not trying to offend you, they are just frustrated with your lack of effort. <br />
<br />
The best thing to do if you are told to do this is to read the manual page.<br />
* To read the program manual page at the command line type:<br />
man <program-name><br />
<br />
If you do not find the answer to your question in the program manual there are more ways to find the answer.You can:<br />
* search the [[Main Page | wiki]]<br />
* search the forum<br />
* search the web<br />
<br />
==testing/[testing]==<br />
This is the repo where major packages/updates to packages are kept prior to release into the main repos, so they can be bug tested and upgrade issues can be found. It is disabled by default, but can be enabled in <code>/etc/pacman.conf</code><br />
<br />
==udev==<br />
udev provides a dynamic device directory containing only the files for actually present devices. It creates or removes device node files in the /dev directory, or it renames network interfaces.<br />
<br />
Usually udev runs as udevd(8) and receives uevents directly from the kernel if a device is added or removed form the system.<br />
<br />
If udev receives a device event, it matches its configured rules against the available device attributes provided in sysfs to identify the device. Rules that match, may provide additional device information or specify a device node name and multiple symlink names and instruct udev to run additional programs as part of the device event handling.<br />
<br />
==unstable/[unstable]==<br />
==versionpkg==<br />
This is a very simple script that allows you to easily update your CVS and SVN packages without having to edit the PKGBUILDs manually to enter the date or revision number. <br />
<br />
Simply run this script rather than makepkg in the build dir. This script completely removes the need for backtick execution to set the date or tag version in PKGBUILDs.<br />
<br />
More detailed information can be found [[Arch_CVS_%26_SVN_PKGBUILD_guidelines#versionpkg_-_a_makepkg_wrapper_for_CVS.2FSVN_builds|here]].<br />
<br />
==wiki==<br />
[[Main Page|This!]] A place to find documentation about ArchLinux. Anyone can add and modify the documentation.</div>Cengichttps://wiki.archlinux.org/index.php?title=Arch_terminology&diff=35639Arch terminology2008-01-26T15:57:01Z<p>Cengic: /* RTFM */</p>
<hr />
<div>[[Category:About Arch (English)]]<br />
[[Category:General (English)]]<br />
=Arch Terminology/Jargon for newbies=<br />
This page is intended to be a page to demystify common terms used among the Arch Linux community. Feel free to add or modify any terms, but please use that particular section's edit option. If you decide to add one, please put it in alphabetical order. <br />
<br />
==ABS==<br />
The Arch Build System (ABS for short) is useful to<br />
* Make new packages of software for which no packages are yet available<br />
* Customize/Modify existing packages to fit your needs (enabling or disabling options)<br />
* Re-build your entire system using your compiler flags, "a la Gentoo" (And getting kernel modules working with your custom kernel!) <br />
ABS is not necessary to use Arch Linux, but it is useful. <br />
<br />
For more information see the [[ABS]] page<br />
<br />
==AUR==<br />
The ArchLinux User-Community Repository (AUR) is a community driven repository for Arch users. The AUR was initially conceived to organize the sharing of PKGBUILDs amongst the wider community and to expedite the inclusion of popular user-contributed packages into the [core] and [extra] repos via the AUR [community] repo. <br />
<br />
It is called to be the birthplace of Arch's new packages. This is because in the AUR, the users contribute their own packages. The AUR community votes for or against them, and eventually, once a package has been voted high enough, a AUR Trusted User takes it to the [community] repository, which is accessible via pacman and ABS.<br />
<br />
You can access the ArchLinux User-Community Repository [http://aur.archlinux.org here]<br />
<br />
==PKGBUILD==<br />
[[ABS PKGBUILD Explained]]<br />
<br />
==TU==<br />
'''T'''rusted '''U'''ser. This is someone who the other TUs have voted into place to manage the AUR and the [community] repository.<br />
<br />
Trusted Users have the ability to mark a package as safe on the AUR, and if it has been voted as popular, move it into the [community] repository.<br />
<br />
Trusted users follow the [[AUR Trusted User Guidelines]] and [http://archlinux.org/~simo/TUbylaws.html TU by-laws]<br />
<br />
==TUR==<br />
'''T'''rusted '''U'''ser '''R'''epository (deprecated)<br />
Before AUR, TUs had their own repositories with (special versions of) applications that weren't available in the official ones. Anyone can make a repository, but TURs were thought to be of a higher quality, because TUs are voted for their knowledge and effort.<br />
<br />
==bbs==<br />
'''B'''ulletin '''B'''oard '''S'''ystem, but in Arch's case it's just the support forum located at http://bbs.archlinux.org.<br />
==community/[community]==<br />
The community repository is where pre-built packages are made available by Trusted Users. A majority of the packages in community, come from the AUR.<br />
<br />
To access the community repository, uncomment it in /etc/pacman.conf.<br />
<br />
==core/[core]==<br />
The Core repository contains the bare packages needed for an Arch System. It has everything needed to get a working command line system<br />
<br />
==custom/user repository==<br />
Anyone can create a repo and put it online so other users can use it. To create a repository, you need a set of packages and a pacman compatible database file for your packages. The DB file is created with [[Custom_local_repository_with_ABS_and_gensync|gensync]]. When you've got both, you can put them online (HTTP or FTP) and everyone will be able to use it by adding it as a regular repository.<br />
<br />
==developer==<br />
Half gods working to improve Arch for no financial gain. Developers are outranked only by our god, Judd Vinet.<br />
<br />
==devfs==<br />
The '''Dev'''ice '''F'''ile '''S'''ystem. DevFS handles, dynamically, the creation, deletion and permission management of device nodes in the /dev directory. It was the default kernel device manager in Arch Linux until release 0.7. Now DevFS is deprecated and in the process of being removed from the Linux kernel. DevFS has been superseded by [[udev]].<br />
<br />
Note that Arch installation CDs prior to 0.7.1 use the devfs naming scheme when creating /etc/fstab entries. See [[DevFS to Udev]].<br />
<br />
==/etc/network-profiles==<br />
In this, you can create various network configurations.<br />
<br />
This is very useful for laptop users that switch networks very often, for example between a home and an office network.<br />
<br />
Additionally it can be used with wpa-supplicant that can manage all of you wireless networks.<br />
For each configuration you need to make a configuration file. The easiest way to do this, is by copying the template.<br />
After you are done with this, you need to enable these in /etc/rc.conf<br />
<br />
After applying changes, you should restart your network by using, as root,<br />
/etc/rc.d/network restart<br />
<br />
==/etc/rc.conf==<br />
/etc/rc.conf is the main system configuration file for Arch Linux. It allows you to set your keyboard, timezone, hostname, network, daemons to run and modules to load at bootup, profiles, and more. Detailed description of the configuration options is given here: [[Rc.conf]]<br />
<br />
==/etc/rc.d==<br />
/etc/rc.d is a directory that contains the scripts that handle starting and stopping of services. On every boot, the services that are present in the DAEMONS= array in /etc/rc.conf are started by running the corresponding scripts in /etc/rc.d.<br />
<br />
It is also possible to control the services from the command line (as root), e.g.,<br />
<br />
/etc/rc.d/cups start<br />
<br />
would start the CUPS daemon. Typical arguments for the scripts are start, stop and restart.<br />
<br />
==/etc/rc.local==<br />
This script is run at the end of every boot. It is intended for miscellaneous commands that you might want to execute before the login prompt. It is not recommended to add any services or settings in /etc/rc.local that could be started or set from /etc/rc.conf instead.<br />
<br />
==extra/[extra]==<br />
Arch's official package set is fairly streamlined, but we supplement this with a larger, more complete "extra" repository that contains a lot of the stuff that never made it into our core package set. This repository is constantly growing with the help of packages submitted from our strong community.<br />
This is where desktop environments, window managers and common programs are found.<br />
<br />
==hotplug==<br />
==hwd==<br />
Hwd; hardware detect for Arch Linux, is for both devfs and udev device systems and also for kernels 2.4.x and 2.6.x. Instead of running an auto configure script what may be expected, Hwd (/usr/bin/hwd) doesn't change existing configures. Detects hardwares and modules, and provides information how to do manually. This allows the user to have a control over his/her system; basic philosophy of Arch Linux.<br />
<br />
Hwd is uploaded in Arch Linux's extra repository. To install, run pacman. <br />
<br />
pacman -S hwd<br />
<br />
here can you see the things you can use Hwd to [http://amlug.net/new-projects/hwd/hwd-46.jpg]<br />
<br />
==hwdetect==<br />
==initramfs==<br />
==initrd==<br />
The special file /dev/initrd is a read-only block device. Device /dev/initrd is a RAM disk that is initialized (e.g. loaded) by the boot loader before the kernel is started. The kernel then can use the block device /dev/initrd's contents for a two phased system boot-up.<br />
<br />
In the first boot-up phase, the kernel starts up and mounts an initial root file-system from the contents of /dev/initrd (e.g. RAM disk initialized by the boot loader). In the second phase, additional drivers or other modules are loaded from the initial root device's contents. After loading the additional modules, a new root file system (i.e. the normal root file system) is mounted from a different device.<br />
<br />
==makepkg==<br />
makepkg will build packages for you. makepkg will read the metadata required from a PKGBUILD file.<br />
All it needs is a build-capable linux platform, wget, and some build scripts. The advantage to a script-based build is that you only really do the work once. Once you have the build script for a package, you just need to run makepkg and it will do the rest: download and validate source files, check dependencies, configure the build time settings, build the package, install the package into a temporary root, make customizations, generate meta-info, and package the whole thing up for pacman to use.<br />
<br />
==namcap==<br />
namcap is a package analysis utility that looks for problems with ArchLinux packages or their PKGBUILD files. It can apply rules to the file list, the files themselves, or individual PKGBUILD files.<br />
<br />
Rules return lists of messages. Each message can be one of three types: error, warning, or information (think of them as notes or comments). Errors (designated by 'E:') are things that namcap is very sure are wrong and need to be fixed. Warnings (designated by 'W:') are things that namcap thinks should be changed but if you know what you're doing then you can leave them. Information (designated 'I:') are only shown when you use the info argument. Information messages give information that might be helpful but isn't anything that needs changing.<br />
<br />
==package==<br />
A package is an archive containing<br />
* all the (compiled) files of an application<br />
* metadata about the application, such as application name, version, dependencies, ...<br />
* installation files and directives for pacman<br />
* (optionally) extra files to make your life easier, such as a start/stop script<br />
Arch's package manager pacman can install, update and remove programs cleanly those packages. Using packages instead of compiling and installing programs yourself has various benefits:<br />
* easily updatable: pacman will update existing packages as soon as updates are available<br />
* dependency checks: pacman handles dependencies for you, you only need to specify the program and pacman installs it together with every other program it needs<br />
* clean removal: pacman has a list of every file in a package. This way no files are left behind when you decide to remove a package<br />
Note: different GNU/Linux distributions use different packages and package manager, meaning that you can't use pacman to install a Debian package on Arch.<br />
<br />
==pacman==<br />
The [[Pacman]] package manager is one of the great highlights of Arch Linux. It combines a simple binary package format with an easy-to-use build system (see ABS). Pacman makes it possible to easily manage and customize packages, whether they be from the official Arch repositories or the user's own creations. The repository system allows users to build and maintain their own custom package repositories, which encourages community growth and contribution (see AUR). <br />
<br />
Pacman can keep a system up to date by synchronizing package lists with the master server, making it a breeze for the security-conscious system administrator to maintain. This server/client model also allows you to download/install packages with a simple command, complete with all required dependencies (similar to Debian's apt-get). <br />
<br />
NB: Pacman was written and is being maintained by Judd Vinet, the creator of Arch Linux. It is used as a package management tool by other distros as well, such as FrugalWare (see also [[1]]), Rubix, UfficioZero (in Italian, based on Ubuntu), and, of course, ArchLinux-derivatives such as Archie and AEGIS.<br />
<br />
==pacman.conf==<br />
This is the configuration file of pacman. It's located in /etc. For a full explanation of its powers<br />
man pacman.conf<br />
<br />
==release/[release]==<br />
Release repository follows the semi-regular snapshot releases and does not update until the next snapshot/iso has been released. For example, the Release repository will point to all packages on the 0.5 ISO until we release 0.6; then it will point to 0.6 packages until 0.7 is released. This is useful if you only want to update your system when a new release is available.<br />
<br />
==repository/repo==<br />
The repository has the pre-compiled packages of one or (usually) more PKGBUILDs. Official repositories are<br />
* core: containing the latest version of packages required for a full CLI system<br />
* extra: containing the latest version of packages not needed for a working system, but needed for an enjoyable system ;)<br />
* community: containing packages that came from [http://aur.archlinux.org AUR] and got enough user votes<br />
Pacman uses these repositories to search for packages and install them. A repository can be local (i.e. on your own computer) or remote (i.e. the packages are downloaded before they're installed).<br />
<br />
==RTFM==<br />
'''R'''ead '''T'''he '''F'''ucking '''M'''anual. This simple message is replied to a lot of new linux/arch users who ask about the functionality of a program, when it is clearly defined in the program's manual.<br />
<br />
It is often used when a user fails to make any attempt to find a solution to the problem themselves. If someone tells you this, they are not trying to offend you, they are just frustrated with your lack of effort. <br />
<br />
The best thing to do if you are told to do this is to read the manual page.<br />
* To read the program manual page at the command line type:<br />
man <program-name><br />
<br />
If you do not find the answer to your question in the program manual there are more ways to find the answer.You can:<br />
* search the [http://wiki.archlinux.org/index.php/Main_Page|wiki]<br />
* search the forum<br />
* search the web<br />
<br />
==testing/[testing]==<br />
This is the repo where major packages/updates to packages are kept prior to release into the main repos, so they can be bug tested and upgrade issues can be found. It is disabled by default, but can be enabled in <code>/etc/pacman.conf</code><br />
<br />
==udev==<br />
udev provides a dynamic device directory containing only the files for actually present devices. It creates or removes device node files in the /dev directory, or it renames network interfaces.<br />
<br />
Usually udev runs as udevd(8) and receives uevents directly from the kernel if a device is added or removed form the system.<br />
<br />
If udev receives a device event, it matches its configured rules against the available device attributes provided in sysfs to identify the device. Rules that match, may provide additional device information or specify a device node name and multiple symlink names and instruct udev to run additional programs as part of the device event handling.<br />
<br />
==unstable/[unstable]==<br />
==versionpkg==<br />
This is a very simple script that allows you to easily update your CVS and SVN packages without having to edit the PKGBUILDs manually to enter the date or revision number. <br />
<br />
Simply run this script rather than makepkg in the build dir. This script completely removes the need for backtick execution to set the date or tag version in PKGBUILDs.<br />
<br />
More detailed information can be found [[Arch_CVS_%26_SVN_PKGBUILD_guidelines#versionpkg_-_a_makepkg_wrapper_for_CVS.2FSVN_builds|here]].<br />
<br />
==wiki==<br />
[[Main Page|This!]] A place to find documentation about ArchLinux. Anyone can add and modify the documentation.</div>Cengichttps://wiki.archlinux.org/index.php?title=Arch_terminology&diff=35638Arch terminology2008-01-26T15:56:41Z<p>Cengic: /* RTFM */</p>
<hr />
<div>[[Category:About Arch (English)]]<br />
[[Category:General (English)]]<br />
=Arch Terminology/Jargon for newbies=<br />
This page is intended to be a page to demystify common terms used among the Arch Linux community. Feel free to add or modify any terms, but please use that particular section's edit option. If you decide to add one, please put it in alphabetical order. <br />
<br />
==ABS==<br />
The Arch Build System (ABS for short) is useful to<br />
* Make new packages of software for which no packages are yet available<br />
* Customize/Modify existing packages to fit your needs (enabling or disabling options)<br />
* Re-build your entire system using your compiler flags, "a la Gentoo" (And getting kernel modules working with your custom kernel!) <br />
ABS is not necessary to use Arch Linux, but it is useful. <br />
<br />
For more information see the [[ABS]] page<br />
<br />
==AUR==<br />
The ArchLinux User-Community Repository (AUR) is a community driven repository for Arch users. The AUR was initially conceived to organize the sharing of PKGBUILDs amongst the wider community and to expedite the inclusion of popular user-contributed packages into the [core] and [extra] repos via the AUR [community] repo. <br />
<br />
It is called to be the birthplace of Arch's new packages. This is because in the AUR, the users contribute their own packages. The AUR community votes for or against them, and eventually, once a package has been voted high enough, a AUR Trusted User takes it to the [community] repository, which is accessible via pacman and ABS.<br />
<br />
You can access the ArchLinux User-Community Repository [http://aur.archlinux.org here]<br />
<br />
==PKGBUILD==<br />
[[ABS PKGBUILD Explained]]<br />
<br />
==TU==<br />
'''T'''rusted '''U'''ser. This is someone who the other TUs have voted into place to manage the AUR and the [community] repository.<br />
<br />
Trusted Users have the ability to mark a package as safe on the AUR, and if it has been voted as popular, move it into the [community] repository.<br />
<br />
Trusted users follow the [[AUR Trusted User Guidelines]] and [http://archlinux.org/~simo/TUbylaws.html TU by-laws]<br />
<br />
==TUR==<br />
'''T'''rusted '''U'''ser '''R'''epository (deprecated)<br />
Before AUR, TUs had their own repositories with (special versions of) applications that weren't available in the official ones. Anyone can make a repository, but TURs were thought to be of a higher quality, because TUs are voted for their knowledge and effort.<br />
<br />
==bbs==<br />
'''B'''ulletin '''B'''oard '''S'''ystem, but in Arch's case it's just the support forum located at http://bbs.archlinux.org.<br />
==community/[community]==<br />
The community repository is where pre-built packages are made available by Trusted Users. A majority of the packages in community, come from the AUR.<br />
<br />
To access the community repository, uncomment it in /etc/pacman.conf.<br />
<br />
==core/[core]==<br />
The Core repository contains the bare packages needed for an Arch System. It has everything needed to get a working command line system<br />
<br />
==custom/user repository==<br />
Anyone can create a repo and put it online so other users can use it. To create a repository, you need a set of packages and a pacman compatible database file for your packages. The DB file is created with [[Custom_local_repository_with_ABS_and_gensync|gensync]]. When you've got both, you can put them online (HTTP or FTP) and everyone will be able to use it by adding it as a regular repository.<br />
<br />
==developer==<br />
Half gods working to improve Arch for no financial gain. Developers are outranked only by our god, Judd Vinet.<br />
<br />
==devfs==<br />
The '''Dev'''ice '''F'''ile '''S'''ystem. DevFS handles, dynamically, the creation, deletion and permission management of device nodes in the /dev directory. It was the default kernel device manager in Arch Linux until release 0.7. Now DevFS is deprecated and in the process of being removed from the Linux kernel. DevFS has been superseded by [[udev]].<br />
<br />
Note that Arch installation CDs prior to 0.7.1 use the devfs naming scheme when creating /etc/fstab entries. See [[DevFS to Udev]].<br />
<br />
==/etc/network-profiles==<br />
In this, you can create various network configurations.<br />
<br />
This is very useful for laptop users that switch networks very often, for example between a home and an office network.<br />
<br />
Additionally it can be used with wpa-supplicant that can manage all of you wireless networks.<br />
For each configuration you need to make a configuration file. The easiest way to do this, is by copying the template.<br />
After you are done with this, you need to enable these in /etc/rc.conf<br />
<br />
After applying changes, you should restart your network by using, as root,<br />
/etc/rc.d/network restart<br />
<br />
==/etc/rc.conf==<br />
/etc/rc.conf is the main system configuration file for Arch Linux. It allows you to set your keyboard, timezone, hostname, network, daemons to run and modules to load at bootup, profiles, and more. Detailed description of the configuration options is given here: [[Rc.conf]]<br />
<br />
==/etc/rc.d==<br />
/etc/rc.d is a directory that contains the scripts that handle starting and stopping of services. On every boot, the services that are present in the DAEMONS= array in /etc/rc.conf are started by running the corresponding scripts in /etc/rc.d.<br />
<br />
It is also possible to control the services from the command line (as root), e.g.,<br />
<br />
/etc/rc.d/cups start<br />
<br />
would start the CUPS daemon. Typical arguments for the scripts are start, stop and restart.<br />
<br />
==/etc/rc.local==<br />
This script is run at the end of every boot. It is intended for miscellaneous commands that you might want to execute before the login prompt. It is not recommended to add any services or settings in /etc/rc.local that could be started or set from /etc/rc.conf instead.<br />
<br />
==extra/[extra]==<br />
Arch's official package set is fairly streamlined, but we supplement this with a larger, more complete "extra" repository that contains a lot of the stuff that never made it into our core package set. This repository is constantly growing with the help of packages submitted from our strong community.<br />
This is where desktop environments, window managers and common programs are found.<br />
<br />
==hotplug==<br />
==hwd==<br />
Hwd; hardware detect for Arch Linux, is for both devfs and udev device systems and also for kernels 2.4.x and 2.6.x. Instead of running an auto configure script what may be expected, Hwd (/usr/bin/hwd) doesn't change existing configures. Detects hardwares and modules, and provides information how to do manually. This allows the user to have a control over his/her system; basic philosophy of Arch Linux.<br />
<br />
Hwd is uploaded in Arch Linux's extra repository. To install, run pacman. <br />
<br />
pacman -S hwd<br />
<br />
here can you see the things you can use Hwd to [http://amlug.net/new-projects/hwd/hwd-46.jpg]<br />
<br />
==hwdetect==<br />
==initramfs==<br />
==initrd==<br />
The special file /dev/initrd is a read-only block device. Device /dev/initrd is a RAM disk that is initialized (e.g. loaded) by the boot loader before the kernel is started. The kernel then can use the block device /dev/initrd's contents for a two phased system boot-up.<br />
<br />
In the first boot-up phase, the kernel starts up and mounts an initial root file-system from the contents of /dev/initrd (e.g. RAM disk initialized by the boot loader). In the second phase, additional drivers or other modules are loaded from the initial root device's contents. After loading the additional modules, a new root file system (i.e. the normal root file system) is mounted from a different device.<br />
<br />
==makepkg==<br />
makepkg will build packages for you. makepkg will read the metadata required from a PKGBUILD file.<br />
All it needs is a build-capable linux platform, wget, and some build scripts. The advantage to a script-based build is that you only really do the work once. Once you have the build script for a package, you just need to run makepkg and it will do the rest: download and validate source files, check dependencies, configure the build time settings, build the package, install the package into a temporary root, make customizations, generate meta-info, and package the whole thing up for pacman to use.<br />
<br />
==namcap==<br />
namcap is a package analysis utility that looks for problems with ArchLinux packages or their PKGBUILD files. It can apply rules to the file list, the files themselves, or individual PKGBUILD files.<br />
<br />
Rules return lists of messages. Each message can be one of three types: error, warning, or information (think of them as notes or comments). Errors (designated by 'E:') are things that namcap is very sure are wrong and need to be fixed. Warnings (designated by 'W:') are things that namcap thinks should be changed but if you know what you're doing then you can leave them. Information (designated 'I:') are only shown when you use the info argument. Information messages give information that might be helpful but isn't anything that needs changing.<br />
<br />
==package==<br />
A package is an archive containing<br />
* all the (compiled) files of an application<br />
* metadata about the application, such as application name, version, dependencies, ...<br />
* installation files and directives for pacman<br />
* (optionally) extra files to make your life easier, such as a start/stop script<br />
Arch's package manager pacman can install, update and remove programs cleanly those packages. Using packages instead of compiling and installing programs yourself has various benefits:<br />
* easily updatable: pacman will update existing packages as soon as updates are available<br />
* dependency checks: pacman handles dependencies for you, you only need to specify the program and pacman installs it together with every other program it needs<br />
* clean removal: pacman has a list of every file in a package. This way no files are left behind when you decide to remove a package<br />
Note: different GNU/Linux distributions use different packages and package manager, meaning that you can't use pacman to install a Debian package on Arch.<br />
<br />
==pacman==<br />
The [[Pacman]] package manager is one of the great highlights of Arch Linux. It combines a simple binary package format with an easy-to-use build system (see ABS). Pacman makes it possible to easily manage and customize packages, whether they be from the official Arch repositories or the user's own creations. The repository system allows users to build and maintain their own custom package repositories, which encourages community growth and contribution (see AUR). <br />
<br />
Pacman can keep a system up to date by synchronizing package lists with the master server, making it a breeze for the security-conscious system administrator to maintain. This server/client model also allows you to download/install packages with a simple command, complete with all required dependencies (similar to Debian's apt-get). <br />
<br />
NB: Pacman was written and is being maintained by Judd Vinet, the creator of Arch Linux. It is used as a package management tool by other distros as well, such as FrugalWare (see also [[1]]), Rubix, UfficioZero (in Italian, based on Ubuntu), and, of course, ArchLinux-derivatives such as Archie and AEGIS.<br />
<br />
==pacman.conf==<br />
This is the configuration file of pacman. It's located in /etc. For a full explanation of its powers<br />
man pacman.conf<br />
<br />
==release/[release]==<br />
Release repository follows the semi-regular snapshot releases and does not update until the next snapshot/iso has been released. For example, the Release repository will point to all packages on the 0.5 ISO until we release 0.6; then it will point to 0.6 packages until 0.7 is released. This is useful if you only want to update your system when a new release is available.<br />
<br />
==repository/repo==<br />
The repository has the pre-compiled packages of one or (usually) more PKGBUILDs. Official repositories are<br />
* core: containing the latest version of packages required for a full CLI system<br />
* extra: containing the latest version of packages not needed for a working system, but needed for an enjoyable system ;)<br />
* community: containing packages that came from [http://aur.archlinux.org AUR] and got enough user votes<br />
Pacman uses these repositories to search for packages and install them. A repository can be local (i.e. on your own computer) or remote (i.e. the packages are downloaded before they're installed).<br />
<br />
==RTFM==<br />
'''R'''ead '''T'''he '''F'''ucking '''M'''anual. This simple message is replied to a lot of new linux/arch users who ask about the functionality of a program, when it is clearly defined in the program's manual.<br />
<br />
It is often used when a user fails to make any attempt to find a solution to the problem themselves. If someone tells you this, they are not trying to offend you, they are just frustrated with your lack of effort. <br />
<br />
The best thing to do if you are told to do this is to read the manual page.<br />
* To read the program manual page at the command line type:<br />
man <program-name><br />
<br />
If you do not find the answer to your question in the program manual there are more ways to find the answer.You can:<br />
* search the [[http://wiki.archlinux.org/index.php/Main_Page|wiki]]<br />
* search the forum<br />
* search the web<br />
<br />
==testing/[testing]==<br />
This is the repo where major packages/updates to packages are kept prior to release into the main repos, so they can be bug tested and upgrade issues can be found. It is disabled by default, but can be enabled in <code>/etc/pacman.conf</code><br />
<br />
==udev==<br />
udev provides a dynamic device directory containing only the files for actually present devices. It creates or removes device node files in the /dev directory, or it renames network interfaces.<br />
<br />
Usually udev runs as udevd(8) and receives uevents directly from the kernel if a device is added or removed form the system.<br />
<br />
If udev receives a device event, it matches its configured rules against the available device attributes provided in sysfs to identify the device. Rules that match, may provide additional device information or specify a device node name and multiple symlink names and instruct udev to run additional programs as part of the device event handling.<br />
<br />
==unstable/[unstable]==<br />
==versionpkg==<br />
This is a very simple script that allows you to easily update your CVS and SVN packages without having to edit the PKGBUILDs manually to enter the date or revision number. <br />
<br />
Simply run this script rather than makepkg in the build dir. This script completely removes the need for backtick execution to set the date or tag version in PKGBUILDs.<br />
<br />
More detailed information can be found [[Arch_CVS_%26_SVN_PKGBUILD_guidelines#versionpkg_-_a_makepkg_wrapper_for_CVS.2FSVN_builds|here]].<br />
<br />
==wiki==<br />
[[Main Page|This!]] A place to find documentation about ArchLinux. Anyone can add and modify the documentation.</div>Cengichttps://wiki.archlinux.org/index.php?title=Arch_terminology&diff=35637Arch terminology2008-01-26T15:53:40Z<p>Cengic: /* RTFM */</p>
<hr />
<div>[[Category:About Arch (English)]]<br />
[[Category:General (English)]]<br />
=Arch Terminology/Jargon for newbies=<br />
This page is intended to be a page to demystify common terms used among the Arch Linux community. Feel free to add or modify any terms, but please use that particular section's edit option. If you decide to add one, please put it in alphabetical order. <br />
<br />
==ABS==<br />
The Arch Build System (ABS for short) is useful to<br />
* Make new packages of software for which no packages are yet available<br />
* Customize/Modify existing packages to fit your needs (enabling or disabling options)<br />
* Re-build your entire system using your compiler flags, "a la Gentoo" (And getting kernel modules working with your custom kernel!) <br />
ABS is not necessary to use Arch Linux, but it is useful. <br />
<br />
For more information see the [[ABS]] page<br />
<br />
==AUR==<br />
The ArchLinux User-Community Repository (AUR) is a community driven repository for Arch users. The AUR was initially conceived to organize the sharing of PKGBUILDs amongst the wider community and to expedite the inclusion of popular user-contributed packages into the [core] and [extra] repos via the AUR [community] repo. <br />
<br />
It is called to be the birthplace of Arch's new packages. This is because in the AUR, the users contribute their own packages. The AUR community votes for or against them, and eventually, once a package has been voted high enough, a AUR Trusted User takes it to the [community] repository, which is accessible via pacman and ABS.<br />
<br />
You can access the ArchLinux User-Community Repository [http://aur.archlinux.org here]<br />
<br />
==PKGBUILD==<br />
[[ABS PKGBUILD Explained]]<br />
<br />
==TU==<br />
'''T'''rusted '''U'''ser. This is someone who the other TUs have voted into place to manage the AUR and the [community] repository.<br />
<br />
Trusted Users have the ability to mark a package as safe on the AUR, and if it has been voted as popular, move it into the [community] repository.<br />
<br />
Trusted users follow the [[AUR Trusted User Guidelines]] and [http://archlinux.org/~simo/TUbylaws.html TU by-laws]<br />
<br />
==TUR==<br />
'''T'''rusted '''U'''ser '''R'''epository (deprecated)<br />
Before AUR, TUs had their own repositories with (special versions of) applications that weren't available in the official ones. Anyone can make a repository, but TURs were thought to be of a higher quality, because TUs are voted for their knowledge and effort.<br />
<br />
==bbs==<br />
'''B'''ulletin '''B'''oard '''S'''ystem, but in Arch's case it's just the support forum located at http://bbs.archlinux.org.<br />
==community/[community]==<br />
The community repository is where pre-built packages are made available by Trusted Users. A majority of the packages in community, come from the AUR.<br />
<br />
To access the community repository, uncomment it in /etc/pacman.conf.<br />
<br />
==core/[core]==<br />
The Core repository contains the bare packages needed for an Arch System. It has everything needed to get a working command line system<br />
<br />
==custom/user repository==<br />
Anyone can create a repo and put it online so other users can use it. To create a repository, you need a set of packages and a pacman compatible database file for your packages. The DB file is created with [[Custom_local_repository_with_ABS_and_gensync|gensync]]. When you've got both, you can put them online (HTTP or FTP) and everyone will be able to use it by adding it as a regular repository.<br />
<br />
==developer==<br />
Half gods working to improve Arch for no financial gain. Developers are outranked only by our god, Judd Vinet.<br />
<br />
==devfs==<br />
The '''Dev'''ice '''F'''ile '''S'''ystem. DevFS handles, dynamically, the creation, deletion and permission management of device nodes in the /dev directory. It was the default kernel device manager in Arch Linux until release 0.7. Now DevFS is deprecated and in the process of being removed from the Linux kernel. DevFS has been superseded by [[udev]].<br />
<br />
Note that Arch installation CDs prior to 0.7.1 use the devfs naming scheme when creating /etc/fstab entries. See [[DevFS to Udev]].<br />
<br />
==/etc/network-profiles==<br />
In this, you can create various network configurations.<br />
<br />
This is very useful for laptop users that switch networks very often, for example between a home and an office network.<br />
<br />
Additionally it can be used with wpa-supplicant that can manage all of you wireless networks.<br />
For each configuration you need to make a configuration file. The easiest way to do this, is by copying the template.<br />
After you are done with this, you need to enable these in /etc/rc.conf<br />
<br />
After applying changes, you should restart your network by using, as root,<br />
/etc/rc.d/network restart<br />
<br />
==/etc/rc.conf==<br />
/etc/rc.conf is the main system configuration file for Arch Linux. It allows you to set your keyboard, timezone, hostname, network, daemons to run and modules to load at bootup, profiles, and more. Detailed description of the configuration options is given here: [[Rc.conf]]<br />
<br />
==/etc/rc.d==<br />
/etc/rc.d is a directory that contains the scripts that handle starting and stopping of services. On every boot, the services that are present in the DAEMONS= array in /etc/rc.conf are started by running the corresponding scripts in /etc/rc.d.<br />
<br />
It is also possible to control the services from the command line (as root), e.g.,<br />
<br />
/etc/rc.d/cups start<br />
<br />
would start the CUPS daemon. Typical arguments for the scripts are start, stop and restart.<br />
<br />
==/etc/rc.local==<br />
This script is run at the end of every boot. It is intended for miscellaneous commands that you might want to execute before the login prompt. It is not recommended to add any services or settings in /etc/rc.local that could be started or set from /etc/rc.conf instead.<br />
<br />
==extra/[extra]==<br />
Arch's official package set is fairly streamlined, but we supplement this with a larger, more complete "extra" repository that contains a lot of the stuff that never made it into our core package set. This repository is constantly growing with the help of packages submitted from our strong community.<br />
This is where desktop environments, window managers and common programs are found.<br />
<br />
==hotplug==<br />
==hwd==<br />
Hwd; hardware detect for Arch Linux, is for both devfs and udev device systems and also for kernels 2.4.x and 2.6.x. Instead of running an auto configure script what may be expected, Hwd (/usr/bin/hwd) doesn't change existing configures. Detects hardwares and modules, and provides information how to do manually. This allows the user to have a control over his/her system; basic philosophy of Arch Linux.<br />
<br />
Hwd is uploaded in Arch Linux's extra repository. To install, run pacman. <br />
<br />
pacman -S hwd<br />
<br />
here can you see the things you can use Hwd to [http://amlug.net/new-projects/hwd/hwd-46.jpg]<br />
<br />
==hwdetect==<br />
==initramfs==<br />
==initrd==<br />
The special file /dev/initrd is a read-only block device. Device /dev/initrd is a RAM disk that is initialized (e.g. loaded) by the boot loader before the kernel is started. The kernel then can use the block device /dev/initrd's contents for a two phased system boot-up.<br />
<br />
In the first boot-up phase, the kernel starts up and mounts an initial root file-system from the contents of /dev/initrd (e.g. RAM disk initialized by the boot loader). In the second phase, additional drivers or other modules are loaded from the initial root device's contents. After loading the additional modules, a new root file system (i.e. the normal root file system) is mounted from a different device.<br />
<br />
==makepkg==<br />
makepkg will build packages for you. makepkg will read the metadata required from a PKGBUILD file.<br />
All it needs is a build-capable linux platform, wget, and some build scripts. The advantage to a script-based build is that you only really do the work once. Once you have the build script for a package, you just need to run makepkg and it will do the rest: download and validate source files, check dependencies, configure the build time settings, build the package, install the package into a temporary root, make customizations, generate meta-info, and package the whole thing up for pacman to use.<br />
<br />
==namcap==<br />
namcap is a package analysis utility that looks for problems with ArchLinux packages or their PKGBUILD files. It can apply rules to the file list, the files themselves, or individual PKGBUILD files.<br />
<br />
Rules return lists of messages. Each message can be one of three types: error, warning, or information (think of them as notes or comments). Errors (designated by 'E:') are things that namcap is very sure are wrong and need to be fixed. Warnings (designated by 'W:') are things that namcap thinks should be changed but if you know what you're doing then you can leave them. Information (designated 'I:') are only shown when you use the info argument. Information messages give information that might be helpful but isn't anything that needs changing.<br />
<br />
==package==<br />
A package is an archive containing<br />
* all the (compiled) files of an application<br />
* metadata about the application, such as application name, version, dependencies, ...<br />
* installation files and directives for pacman<br />
* (optionally) extra files to make your life easier, such as a start/stop script<br />
Arch's package manager pacman can install, update and remove programs cleanly those packages. Using packages instead of compiling and installing programs yourself has various benefits:<br />
* easily updatable: pacman will update existing packages as soon as updates are available<br />
* dependency checks: pacman handles dependencies for you, you only need to specify the program and pacman installs it together with every other program it needs<br />
* clean removal: pacman has a list of every file in a package. This way no files are left behind when you decide to remove a package<br />
Note: different GNU/Linux distributions use different packages and package manager, meaning that you can't use pacman to install a Debian package on Arch.<br />
<br />
==pacman==<br />
The [[Pacman]] package manager is one of the great highlights of Arch Linux. It combines a simple binary package format with an easy-to-use build system (see ABS). Pacman makes it possible to easily manage and customize packages, whether they be from the official Arch repositories or the user's own creations. The repository system allows users to build and maintain their own custom package repositories, which encourages community growth and contribution (see AUR). <br />
<br />
Pacman can keep a system up to date by synchronizing package lists with the master server, making it a breeze for the security-conscious system administrator to maintain. This server/client model also allows you to download/install packages with a simple command, complete with all required dependencies (similar to Debian's apt-get). <br />
<br />
NB: Pacman was written and is being maintained by Judd Vinet, the creator of Arch Linux. It is used as a package management tool by other distros as well, such as FrugalWare (see also [[1]]), Rubix, UfficioZero (in Italian, based on Ubuntu), and, of course, ArchLinux-derivatives such as Archie and AEGIS.<br />
<br />
==pacman.conf==<br />
This is the configuration file of pacman. It's located in /etc. For a full explanation of its powers<br />
man pacman.conf<br />
<br />
==release/[release]==<br />
Release repository follows the semi-regular snapshot releases and does not update until the next snapshot/iso has been released. For example, the Release repository will point to all packages on the 0.5 ISO until we release 0.6; then it will point to 0.6 packages until 0.7 is released. This is useful if you only want to update your system when a new release is available.<br />
<br />
==repository/repo==<br />
The repository has the pre-compiled packages of one or (usually) more PKGBUILDs. Official repositories are<br />
* core: containing the latest version of packages required for a full CLI system<br />
* extra: containing the latest version of packages not needed for a working system, but needed for an enjoyable system ;)<br />
* community: containing packages that came from [http://aur.archlinux.org AUR] and got enough user votes<br />
Pacman uses these repositories to search for packages and install them. A repository can be local (i.e. on your own computer) or remote (i.e. the packages are downloaded before they're installed).<br />
<br />
==RTFM==<br />
'''R'''ead '''T'''he '''F'''ucking '''M'''anual. This simple message is replied to a lot of new linux/arch users who ask about the functionality of a program, when it is clearly defined in the program's manual.<br />
<br />
It is often used when a user fails to make any attempt to find a solution to the problem themselves. If someone tells you this, they are not trying to offend you, they are just frustrated with your lack of effort. <br />
<br />
The best thing to do if you are told to do this is to read the manual page.<br />
* To read the program manual page at the command line type:<br />
man <program-name><br />
<br />
If you do not find the answer to your question in the program manual there are more ways to find the answer.You can:<br />
* search the wiki<br />
* search the forum<br />
* search the web<br />
<br />
==testing/[testing]==<br />
This is the repo where major packages/updates to packages are kept prior to release into the main repos, so they can be bug tested and upgrade issues can be found. It is disabled by default, but can be enabled in <code>/etc/pacman.conf</code><br />
<br />
==udev==<br />
udev provides a dynamic device directory containing only the files for actually present devices. It creates or removes device node files in the /dev directory, or it renames network interfaces.<br />
<br />
Usually udev runs as udevd(8) and receives uevents directly from the kernel if a device is added or removed form the system.<br />
<br />
If udev receives a device event, it matches its configured rules against the available device attributes provided in sysfs to identify the device. Rules that match, may provide additional device information or specify a device node name and multiple symlink names and instruct udev to run additional programs as part of the device event handling.<br />
<br />
==unstable/[unstable]==<br />
==versionpkg==<br />
This is a very simple script that allows you to easily update your CVS and SVN packages without having to edit the PKGBUILDs manually to enter the date or revision number. <br />
<br />
Simply run this script rather than makepkg in the build dir. This script completely removes the need for backtick execution to set the date or tag version in PKGBUILDs.<br />
<br />
More detailed information can be found [[Arch_CVS_%26_SVN_PKGBUILD_guidelines#versionpkg_-_a_makepkg_wrapper_for_CVS.2FSVN_builds|here]].<br />
<br />
==wiki==<br />
[[Main Page|This!]] A place to find documentation about ArchLinux. Anyone can add and modify the documentation.</div>Cengichttps://wiki.archlinux.org/index.php?title=Arch_terminology&diff=35636Arch terminology2008-01-26T15:52:58Z<p>Cengic: /* RTFM */</p>
<hr />
<div>[[Category:About Arch (English)]]<br />
[[Category:General (English)]]<br />
=Arch Terminology/Jargon for newbies=<br />
This page is intended to be a page to demystify common terms used among the Arch Linux community. Feel free to add or modify any terms, but please use that particular section's edit option. If you decide to add one, please put it in alphabetical order. <br />
<br />
==ABS==<br />
The Arch Build System (ABS for short) is useful to<br />
* Make new packages of software for which no packages are yet available<br />
* Customize/Modify existing packages to fit your needs (enabling or disabling options)<br />
* Re-build your entire system using your compiler flags, "a la Gentoo" (And getting kernel modules working with your custom kernel!) <br />
ABS is not necessary to use Arch Linux, but it is useful. <br />
<br />
For more information see the [[ABS]] page<br />
<br />
==AUR==<br />
The ArchLinux User-Community Repository (AUR) is a community driven repository for Arch users. The AUR was initially conceived to organize the sharing of PKGBUILDs amongst the wider community and to expedite the inclusion of popular user-contributed packages into the [core] and [extra] repos via the AUR [community] repo. <br />
<br />
It is called to be the birthplace of Arch's new packages. This is because in the AUR, the users contribute their own packages. The AUR community votes for or against them, and eventually, once a package has been voted high enough, a AUR Trusted User takes it to the [community] repository, which is accessible via pacman and ABS.<br />
<br />
You can access the ArchLinux User-Community Repository [http://aur.archlinux.org here]<br />
<br />
==PKGBUILD==<br />
[[ABS PKGBUILD Explained]]<br />
<br />
==TU==<br />
'''T'''rusted '''U'''ser. This is someone who the other TUs have voted into place to manage the AUR and the [community] repository.<br />
<br />
Trusted Users have the ability to mark a package as safe on the AUR, and if it has been voted as popular, move it into the [community] repository.<br />
<br />
Trusted users follow the [[AUR Trusted User Guidelines]] and [http://archlinux.org/~simo/TUbylaws.html TU by-laws]<br />
<br />
==TUR==<br />
'''T'''rusted '''U'''ser '''R'''epository (deprecated)<br />
Before AUR, TUs had their own repositories with (special versions of) applications that weren't available in the official ones. Anyone can make a repository, but TURs were thought to be of a higher quality, because TUs are voted for their knowledge and effort.<br />
<br />
==bbs==<br />
'''B'''ulletin '''B'''oard '''S'''ystem, but in Arch's case it's just the support forum located at http://bbs.archlinux.org.<br />
==community/[community]==<br />
The community repository is where pre-built packages are made available by Trusted Users. A majority of the packages in community, come from the AUR.<br />
<br />
To access the community repository, uncomment it in /etc/pacman.conf.<br />
<br />
==core/[core]==<br />
The Core repository contains the bare packages needed for an Arch System. It has everything needed to get a working command line system<br />
<br />
==custom/user repository==<br />
Anyone can create a repo and put it online so other users can use it. To create a repository, you need a set of packages and a pacman compatible database file for your packages. The DB file is created with [[Custom_local_repository_with_ABS_and_gensync|gensync]]. When you've got both, you can put them online (HTTP or FTP) and everyone will be able to use it by adding it as a regular repository.<br />
<br />
==developer==<br />
Half gods working to improve Arch for no financial gain. Developers are outranked only by our god, Judd Vinet.<br />
<br />
==devfs==<br />
The '''Dev'''ice '''F'''ile '''S'''ystem. DevFS handles, dynamically, the creation, deletion and permission management of device nodes in the /dev directory. It was the default kernel device manager in Arch Linux until release 0.7. Now DevFS is deprecated and in the process of being removed from the Linux kernel. DevFS has been superseded by [[udev]].<br />
<br />
Note that Arch installation CDs prior to 0.7.1 use the devfs naming scheme when creating /etc/fstab entries. See [[DevFS to Udev]].<br />
<br />
==/etc/network-profiles==<br />
In this, you can create various network configurations.<br />
<br />
This is very useful for laptop users that switch networks very often, for example between a home and an office network.<br />
<br />
Additionally it can be used with wpa-supplicant that can manage all of you wireless networks.<br />
For each configuration you need to make a configuration file. The easiest way to do this, is by copying the template.<br />
After you are done with this, you need to enable these in /etc/rc.conf<br />
<br />
After applying changes, you should restart your network by using, as root,<br />
/etc/rc.d/network restart<br />
<br />
==/etc/rc.conf==<br />
/etc/rc.conf is the main system configuration file for Arch Linux. It allows you to set your keyboard, timezone, hostname, network, daemons to run and modules to load at bootup, profiles, and more. Detailed description of the configuration options is given here: [[Rc.conf]]<br />
<br />
==/etc/rc.d==<br />
/etc/rc.d is a directory that contains the scripts that handle starting and stopping of services. On every boot, the services that are present in the DAEMONS= array in /etc/rc.conf are started by running the corresponding scripts in /etc/rc.d.<br />
<br />
It is also possible to control the services from the command line (as root), e.g.,<br />
<br />
/etc/rc.d/cups start<br />
<br />
would start the CUPS daemon. Typical arguments for the scripts are start, stop and restart.<br />
<br />
==/etc/rc.local==<br />
This script is run at the end of every boot. It is intended for miscellaneous commands that you might want to execute before the login prompt. It is not recommended to add any services or settings in /etc/rc.local that could be started or set from /etc/rc.conf instead.<br />
<br />
==extra/[extra]==<br />
Arch's official package set is fairly streamlined, but we supplement this with a larger, more complete "extra" repository that contains a lot of the stuff that never made it into our core package set. This repository is constantly growing with the help of packages submitted from our strong community.<br />
This is where desktop environments, window managers and common programs are found.<br />
<br />
==hotplug==<br />
==hwd==<br />
Hwd; hardware detect for Arch Linux, is for both devfs and udev device systems and also for kernels 2.4.x and 2.6.x. Instead of running an auto configure script what may be expected, Hwd (/usr/bin/hwd) doesn't change existing configures. Detects hardwares and modules, and provides information how to do manually. This allows the user to have a control over his/her system; basic philosophy of Arch Linux.<br />
<br />
Hwd is uploaded in Arch Linux's extra repository. To install, run pacman. <br />
<br />
pacman -S hwd<br />
<br />
here can you see the things you can use Hwd to [http://amlug.net/new-projects/hwd/hwd-46.jpg]<br />
<br />
==hwdetect==<br />
==initramfs==<br />
==initrd==<br />
The special file /dev/initrd is a read-only block device. Device /dev/initrd is a RAM disk that is initialized (e.g. loaded) by the boot loader before the kernel is started. The kernel then can use the block device /dev/initrd's contents for a two phased system boot-up.<br />
<br />
In the first boot-up phase, the kernel starts up and mounts an initial root file-system from the contents of /dev/initrd (e.g. RAM disk initialized by the boot loader). In the second phase, additional drivers or other modules are loaded from the initial root device's contents. After loading the additional modules, a new root file system (i.e. the normal root file system) is mounted from a different device.<br />
<br />
==makepkg==<br />
makepkg will build packages for you. makepkg will read the metadata required from a PKGBUILD file.<br />
All it needs is a build-capable linux platform, wget, and some build scripts. The advantage to a script-based build is that you only really do the work once. Once you have the build script for a package, you just need to run makepkg and it will do the rest: download and validate source files, check dependencies, configure the build time settings, build the package, install the package into a temporary root, make customizations, generate meta-info, and package the whole thing up for pacman to use.<br />
<br />
==namcap==<br />
namcap is a package analysis utility that looks for problems with ArchLinux packages or their PKGBUILD files. It can apply rules to the file list, the files themselves, or individual PKGBUILD files.<br />
<br />
Rules return lists of messages. Each message can be one of three types: error, warning, or information (think of them as notes or comments). Errors (designated by 'E:') are things that namcap is very sure are wrong and need to be fixed. Warnings (designated by 'W:') are things that namcap thinks should be changed but if you know what you're doing then you can leave them. Information (designated 'I:') are only shown when you use the info argument. Information messages give information that might be helpful but isn't anything that needs changing.<br />
<br />
==package==<br />
A package is an archive containing<br />
* all the (compiled) files of an application<br />
* metadata about the application, such as application name, version, dependencies, ...<br />
* installation files and directives for pacman<br />
* (optionally) extra files to make your life easier, such as a start/stop script<br />
Arch's package manager pacman can install, update and remove programs cleanly those packages. Using packages instead of compiling and installing programs yourself has various benefits:<br />
* easily updatable: pacman will update existing packages as soon as updates are available<br />
* dependency checks: pacman handles dependencies for you, you only need to specify the program and pacman installs it together with every other program it needs<br />
* clean removal: pacman has a list of every file in a package. This way no files are left behind when you decide to remove a package<br />
Note: different GNU/Linux distributions use different packages and package manager, meaning that you can't use pacman to install a Debian package on Arch.<br />
<br />
==pacman==<br />
The [[Pacman]] package manager is one of the great highlights of Arch Linux. It combines a simple binary package format with an easy-to-use build system (see ABS). Pacman makes it possible to easily manage and customize packages, whether they be from the official Arch repositories or the user's own creations. The repository system allows users to build and maintain their own custom package repositories, which encourages community growth and contribution (see AUR). <br />
<br />
Pacman can keep a system up to date by synchronizing package lists with the master server, making it a breeze for the security-conscious system administrator to maintain. This server/client model also allows you to download/install packages with a simple command, complete with all required dependencies (similar to Debian's apt-get). <br />
<br />
NB: Pacman was written and is being maintained by Judd Vinet, the creator of Arch Linux. It is used as a package management tool by other distros as well, such as FrugalWare (see also [[1]]), Rubix, UfficioZero (in Italian, based on Ubuntu), and, of course, ArchLinux-derivatives such as Archie and AEGIS.<br />
<br />
==pacman.conf==<br />
This is the configuration file of pacman. It's located in /etc. For a full explanation of its powers<br />
man pacman.conf<br />
<br />
==release/[release]==<br />
Release repository follows the semi-regular snapshot releases and does not update until the next snapshot/iso has been released. For example, the Release repository will point to all packages on the 0.5 ISO until we release 0.6; then it will point to 0.6 packages until 0.7 is released. This is useful if you only want to update your system when a new release is available.<br />
<br />
==repository/repo==<br />
The repository has the pre-compiled packages of one or (usually) more PKGBUILDs. Official repositories are<br />
* core: containing the latest version of packages required for a full CLI system<br />
* extra: containing the latest version of packages not needed for a working system, but needed for an enjoyable system ;)<br />
* community: containing packages that came from [http://aur.archlinux.org AUR] and got enough user votes<br />
Pacman uses these repositories to search for packages and install them. A repository can be local (i.e. on your own computer) or remote (i.e. the packages are downloaded before they're installed).<br />
<br />
==RTFM==<br />
'''R'''ead '''T'''he '''F'''ucking '''M'''anual. This simple message is replied to a lot of new linux/arch users who ask about the functionality of a program, when it is clearly defined in the program's manual.<br />
<br />
It is often used when a user fails to make any attempt to find a solution to the problem themselves. If someone tells you this, they are not trying to offend you, they are just frustrated with your lack of effort. <br />
<br />
The best thing to do if you are told to do this is to read the manual page.<br />
* To read the program manual page at the command line type:<br />
man <program-name><br />
<br />
If you do not find the answer to you question there are more ways to find the answer.You can:<br />
* search the wiki<br />
* search the forum<br />
* search the web<br />
<br />
==testing/[testing]==<br />
This is the repo where major packages/updates to packages are kept prior to release into the main repos, so they can be bug tested and upgrade issues can be found. It is disabled by default, but can be enabled in <code>/etc/pacman.conf</code><br />
<br />
==udev==<br />
udev provides a dynamic device directory containing only the files for actually present devices. It creates or removes device node files in the /dev directory, or it renames network interfaces.<br />
<br />
Usually udev runs as udevd(8) and receives uevents directly from the kernel if a device is added or removed form the system.<br />
<br />
If udev receives a device event, it matches its configured rules against the available device attributes provided in sysfs to identify the device. Rules that match, may provide additional device information or specify a device node name and multiple symlink names and instruct udev to run additional programs as part of the device event handling.<br />
<br />
==unstable/[unstable]==<br />
==versionpkg==<br />
This is a very simple script that allows you to easily update your CVS and SVN packages without having to edit the PKGBUILDs manually to enter the date or revision number. <br />
<br />
Simply run this script rather than makepkg in the build dir. This script completely removes the need for backtick execution to set the date or tag version in PKGBUILDs.<br />
<br />
More detailed information can be found [[Arch_CVS_%26_SVN_PKGBUILD_guidelines#versionpkg_-_a_makepkg_wrapper_for_CVS.2FSVN_builds|here]].<br />
<br />
==wiki==<br />
[[Main Page|This!]] A place to find documentation about ArchLinux. Anyone can add and modify the documentation.</div>Cengichttps://wiki.archlinux.org/index.php?title=Arch_terminology&diff=35635Arch terminology2008-01-26T15:51:47Z<p>Cengic: /* RTFM */</p>
<hr />
<div>[[Category:About Arch (English)]]<br />
[[Category:General (English)]]<br />
=Arch Terminology/Jargon for newbies=<br />
This page is intended to be a page to demystify common terms used among the Arch Linux community. Feel free to add or modify any terms, but please use that particular section's edit option. If you decide to add one, please put it in alphabetical order. <br />
<br />
==ABS==<br />
The Arch Build System (ABS for short) is useful to<br />
* Make new packages of software for which no packages are yet available<br />
* Customize/Modify existing packages to fit your needs (enabling or disabling options)<br />
* Re-build your entire system using your compiler flags, "a la Gentoo" (And getting kernel modules working with your custom kernel!) <br />
ABS is not necessary to use Arch Linux, but it is useful. <br />
<br />
For more information see the [[ABS]] page<br />
<br />
==AUR==<br />
The ArchLinux User-Community Repository (AUR) is a community driven repository for Arch users. The AUR was initially conceived to organize the sharing of PKGBUILDs amongst the wider community and to expedite the inclusion of popular user-contributed packages into the [core] and [extra] repos via the AUR [community] repo. <br />
<br />
It is called to be the birthplace of Arch's new packages. This is because in the AUR, the users contribute their own packages. The AUR community votes for or against them, and eventually, once a package has been voted high enough, a AUR Trusted User takes it to the [community] repository, which is accessible via pacman and ABS.<br />
<br />
You can access the ArchLinux User-Community Repository [http://aur.archlinux.org here]<br />
<br />
==PKGBUILD==<br />
[[ABS PKGBUILD Explained]]<br />
<br />
==TU==<br />
'''T'''rusted '''U'''ser. This is someone who the other TUs have voted into place to manage the AUR and the [community] repository.<br />
<br />
Trusted Users have the ability to mark a package as safe on the AUR, and if it has been voted as popular, move it into the [community] repository.<br />
<br />
Trusted users follow the [[AUR Trusted User Guidelines]] and [http://archlinux.org/~simo/TUbylaws.html TU by-laws]<br />
<br />
==TUR==<br />
'''T'''rusted '''U'''ser '''R'''epository (deprecated)<br />
Before AUR, TUs had their own repositories with (special versions of) applications that weren't available in the official ones. Anyone can make a repository, but TURs were thought to be of a higher quality, because TUs are voted for their knowledge and effort.<br />
<br />
==bbs==<br />
'''B'''ulletin '''B'''oard '''S'''ystem, but in Arch's case it's just the support forum located at http://bbs.archlinux.org.<br />
==community/[community]==<br />
The community repository is where pre-built packages are made available by Trusted Users. A majority of the packages in community, come from the AUR.<br />
<br />
To access the community repository, uncomment it in /etc/pacman.conf.<br />
<br />
==core/[core]==<br />
The Core repository contains the bare packages needed for an Arch System. It has everything needed to get a working command line system<br />
<br />
==custom/user repository==<br />
Anyone can create a repo and put it online so other users can use it. To create a repository, you need a set of packages and a pacman compatible database file for your packages. The DB file is created with [[Custom_local_repository_with_ABS_and_gensync|gensync]]. When you've got both, you can put them online (HTTP or FTP) and everyone will be able to use it by adding it as a regular repository.<br />
<br />
==developer==<br />
Half gods working to improve Arch for no financial gain. Developers are outranked only by our god, Judd Vinet.<br />
<br />
==devfs==<br />
The '''Dev'''ice '''F'''ile '''S'''ystem. DevFS handles, dynamically, the creation, deletion and permission management of device nodes in the /dev directory. It was the default kernel device manager in Arch Linux until release 0.7. Now DevFS is deprecated and in the process of being removed from the Linux kernel. DevFS has been superseded by [[udev]].<br />
<br />
Note that Arch installation CDs prior to 0.7.1 use the devfs naming scheme when creating /etc/fstab entries. See [[DevFS to Udev]].<br />
<br />
==/etc/network-profiles==<br />
In this, you can create various network configurations.<br />
<br />
This is very useful for laptop users that switch networks very often, for example between a home and an office network.<br />
<br />
Additionally it can be used with wpa-supplicant that can manage all of you wireless networks.<br />
For each configuration you need to make a configuration file. The easiest way to do this, is by copying the template.<br />
After you are done with this, you need to enable these in /etc/rc.conf<br />
<br />
After applying changes, you should restart your network by using, as root,<br />
/etc/rc.d/network restart<br />
<br />
==/etc/rc.conf==<br />
/etc/rc.conf is the main system configuration file for Arch Linux. It allows you to set your keyboard, timezone, hostname, network, daemons to run and modules to load at bootup, profiles, and more. Detailed description of the configuration options is given here: [[Rc.conf]]<br />
<br />
==/etc/rc.d==<br />
/etc/rc.d is a directory that contains the scripts that handle starting and stopping of services. On every boot, the services that are present in the DAEMONS= array in /etc/rc.conf are started by running the corresponding scripts in /etc/rc.d.<br />
<br />
It is also possible to control the services from the command line (as root), e.g.,<br />
<br />
/etc/rc.d/cups start<br />
<br />
would start the CUPS daemon. Typical arguments for the scripts are start, stop and restart.<br />
<br />
==/etc/rc.local==<br />
This script is run at the end of every boot. It is intended for miscellaneous commands that you might want to execute before the login prompt. It is not recommended to add any services or settings in /etc/rc.local that could be started or set from /etc/rc.conf instead.<br />
<br />
==extra/[extra]==<br />
Arch's official package set is fairly streamlined, but we supplement this with a larger, more complete "extra" repository that contains a lot of the stuff that never made it into our core package set. This repository is constantly growing with the help of packages submitted from our strong community.<br />
This is where desktop environments, window managers and common programs are found.<br />
<br />
==hotplug==<br />
==hwd==<br />
Hwd; hardware detect for Arch Linux, is for both devfs and udev device systems and also for kernels 2.4.x and 2.6.x. Instead of running an auto configure script what may be expected, Hwd (/usr/bin/hwd) doesn't change existing configures. Detects hardwares and modules, and provides information how to do manually. This allows the user to have a control over his/her system; basic philosophy of Arch Linux.<br />
<br />
Hwd is uploaded in Arch Linux's extra repository. To install, run pacman. <br />
<br />
pacman -S hwd<br />
<br />
here can you see the things you can use Hwd to [http://amlug.net/new-projects/hwd/hwd-46.jpg]<br />
<br />
==hwdetect==<br />
==initramfs==<br />
==initrd==<br />
The special file /dev/initrd is a read-only block device. Device /dev/initrd is a RAM disk that is initialized (e.g. loaded) by the boot loader before the kernel is started. The kernel then can use the block device /dev/initrd's contents for a two phased system boot-up.<br />
<br />
In the first boot-up phase, the kernel starts up and mounts an initial root file-system from the contents of /dev/initrd (e.g. RAM disk initialized by the boot loader). In the second phase, additional drivers or other modules are loaded from the initial root device's contents. After loading the additional modules, a new root file system (i.e. the normal root file system) is mounted from a different device.<br />
<br />
==makepkg==<br />
makepkg will build packages for you. makepkg will read the metadata required from a PKGBUILD file.<br />
All it needs is a build-capable linux platform, wget, and some build scripts. The advantage to a script-based build is that you only really do the work once. Once you have the build script for a package, you just need to run makepkg and it will do the rest: download and validate source files, check dependencies, configure the build time settings, build the package, install the package into a temporary root, make customizations, generate meta-info, and package the whole thing up for pacman to use.<br />
<br />
==namcap==<br />
namcap is a package analysis utility that looks for problems with ArchLinux packages or their PKGBUILD files. It can apply rules to the file list, the files themselves, or individual PKGBUILD files.<br />
<br />
Rules return lists of messages. Each message can be one of three types: error, warning, or information (think of them as notes or comments). Errors (designated by 'E:') are things that namcap is very sure are wrong and need to be fixed. Warnings (designated by 'W:') are things that namcap thinks should be changed but if you know what you're doing then you can leave them. Information (designated 'I:') are only shown when you use the info argument. Information messages give information that might be helpful but isn't anything that needs changing.<br />
<br />
==package==<br />
A package is an archive containing<br />
* all the (compiled) files of an application<br />
* metadata about the application, such as application name, version, dependencies, ...<br />
* installation files and directives for pacman<br />
* (optionally) extra files to make your life easier, such as a start/stop script<br />
Arch's package manager pacman can install, update and remove programs cleanly those packages. Using packages instead of compiling and installing programs yourself has various benefits:<br />
* easily updatable: pacman will update existing packages as soon as updates are available<br />
* dependency checks: pacman handles dependencies for you, you only need to specify the program and pacman installs it together with every other program it needs<br />
* clean removal: pacman has a list of every file in a package. This way no files are left behind when you decide to remove a package<br />
Note: different GNU/Linux distributions use different packages and package manager, meaning that you can't use pacman to install a Debian package on Arch.<br />
<br />
==pacman==<br />
The [[Pacman]] package manager is one of the great highlights of Arch Linux. It combines a simple binary package format with an easy-to-use build system (see ABS). Pacman makes it possible to easily manage and customize packages, whether they be from the official Arch repositories or the user's own creations. The repository system allows users to build and maintain their own custom package repositories, which encourages community growth and contribution (see AUR). <br />
<br />
Pacman can keep a system up to date by synchronizing package lists with the master server, making it a breeze for the security-conscious system administrator to maintain. This server/client model also allows you to download/install packages with a simple command, complete with all required dependencies (similar to Debian's apt-get). <br />
<br />
NB: Pacman was written and is being maintained by Judd Vinet, the creator of Arch Linux. It is used as a package management tool by other distros as well, such as FrugalWare (see also [[1]]), Rubix, UfficioZero (in Italian, based on Ubuntu), and, of course, ArchLinux-derivatives such as Archie and AEGIS.<br />
<br />
==pacman.conf==<br />
This is the configuration file of pacman. It's located in /etc. For a full explanation of its powers<br />
man pacman.conf<br />
<br />
==release/[release]==<br />
Release repository follows the semi-regular snapshot releases and does not update until the next snapshot/iso has been released. For example, the Release repository will point to all packages on the 0.5 ISO until we release 0.6; then it will point to 0.6 packages until 0.7 is released. This is useful if you only want to update your system when a new release is available.<br />
<br />
==repository/repo==<br />
The repository has the pre-compiled packages of one or (usually) more PKGBUILDs. Official repositories are<br />
* core: containing the latest version of packages required for a full CLI system<br />
* extra: containing the latest version of packages not needed for a working system, but needed for an enjoyable system ;)<br />
* community: containing packages that came from [http://aur.archlinux.org AUR] and got enough user votes<br />
Pacman uses these repositories to search for packages and install them. A repository can be local (i.e. on your own computer) or remote (i.e. the packages are downloaded before they're installed).<br />
<br />
==RTFM==<br />
'''R'''ead '''T'''he '''F'''ucking '''M'''anual. This simple message is replied to a lot of new linux/arch users who ask about the functionality of a program, when it is clearly defined in the program's manual.<br />
<br />
It is often used when a user fails to make any attempt to find a solution to the problem themselves. If someone tells you this, they are not trying to offend you, they are just frustrated with your lack of effort. <br />
<br />
The best thing to do if you are told to do this is to read the manual page:<br />
<br />
* Read the program man page, at a command line type:<br />
man <program-name><br />
<br />
If you do not find the answer to you question there are more ways to find the answer.You can:<br />
* search the wiki<br />
* search the forum<br />
* search the web<br />
<br />
==testing/[testing]==<br />
This is the repo where major packages/updates to packages are kept prior to release into the main repos, so they can be bug tested and upgrade issues can be found. It is disabled by default, but can be enabled in <code>/etc/pacman.conf</code><br />
<br />
==udev==<br />
udev provides a dynamic device directory containing only the files for actually present devices. It creates or removes device node files in the /dev directory, or it renames network interfaces.<br />
<br />
Usually udev runs as udevd(8) and receives uevents directly from the kernel if a device is added or removed form the system.<br />
<br />
If udev receives a device event, it matches its configured rules against the available device attributes provided in sysfs to identify the device. Rules that match, may provide additional device information or specify a device node name and multiple symlink names and instruct udev to run additional programs as part of the device event handling.<br />
<br />
==unstable/[unstable]==<br />
==versionpkg==<br />
This is a very simple script that allows you to easily update your CVS and SVN packages without having to edit the PKGBUILDs manually to enter the date or revision number. <br />
<br />
Simply run this script rather than makepkg in the build dir. This script completely removes the need for backtick execution to set the date or tag version in PKGBUILDs.<br />
<br />
More detailed information can be found [[Arch_CVS_%26_SVN_PKGBUILD_guidelines#versionpkg_-_a_makepkg_wrapper_for_CVS.2FSVN_builds|here]].<br />
<br />
==wiki==<br />
[[Main Page|This!]] A place to find documentation about ArchLinux. Anyone can add and modify the documentation.</div>Cengichttps://wiki.archlinux.org/index.php?title=Arch_terminology&diff=35634Arch terminology2008-01-26T15:48:51Z<p>Cengic: /* RTFM */</p>
<hr />
<div>[[Category:About Arch (English)]]<br />
[[Category:General (English)]]<br />
=Arch Terminology/Jargon for newbies=<br />
This page is intended to be a page to demystify common terms used among the Arch Linux community. Feel free to add or modify any terms, but please use that particular section's edit option. If you decide to add one, please put it in alphabetical order. <br />
<br />
==ABS==<br />
The Arch Build System (ABS for short) is useful to<br />
* Make new packages of software for which no packages are yet available<br />
* Customize/Modify existing packages to fit your needs (enabling or disabling options)<br />
* Re-build your entire system using your compiler flags, "a la Gentoo" (And getting kernel modules working with your custom kernel!) <br />
ABS is not necessary to use Arch Linux, but it is useful. <br />
<br />
For more information see the [[ABS]] page<br />
<br />
==AUR==<br />
The ArchLinux User-Community Repository (AUR) is a community driven repository for Arch users. The AUR was initially conceived to organize the sharing of PKGBUILDs amongst the wider community and to expedite the inclusion of popular user-contributed packages into the [core] and [extra] repos via the AUR [community] repo. <br />
<br />
It is called to be the birthplace of Arch's new packages. This is because in the AUR, the users contribute their own packages. The AUR community votes for or against them, and eventually, once a package has been voted high enough, a AUR Trusted User takes it to the [community] repository, which is accessible via pacman and ABS.<br />
<br />
You can access the ArchLinux User-Community Repository [http://aur.archlinux.org here]<br />
<br />
==PKGBUILD==<br />
[[ABS PKGBUILD Explained]]<br />
<br />
==TU==<br />
'''T'''rusted '''U'''ser. This is someone who the other TUs have voted into place to manage the AUR and the [community] repository.<br />
<br />
Trusted Users have the ability to mark a package as safe on the AUR, and if it has been voted as popular, move it into the [community] repository.<br />
<br />
Trusted users follow the [[AUR Trusted User Guidelines]] and [http://archlinux.org/~simo/TUbylaws.html TU by-laws]<br />
<br />
==TUR==<br />
'''T'''rusted '''U'''ser '''R'''epository (deprecated)<br />
Before AUR, TUs had their own repositories with (special versions of) applications that weren't available in the official ones. Anyone can make a repository, but TURs were thought to be of a higher quality, because TUs are voted for their knowledge and effort.<br />
<br />
==bbs==<br />
'''B'''ulletin '''B'''oard '''S'''ystem, but in Arch's case it's just the support forum located at http://bbs.archlinux.org.<br />
==community/[community]==<br />
The community repository is where pre-built packages are made available by Trusted Users. A majority of the packages in community, come from the AUR.<br />
<br />
To access the community repository, uncomment it in /etc/pacman.conf.<br />
<br />
==core/[core]==<br />
The Core repository contains the bare packages needed for an Arch System. It has everything needed to get a working command line system<br />
<br />
==custom/user repository==<br />
Anyone can create a repo and put it online so other users can use it. To create a repository, you need a set of packages and a pacman compatible database file for your packages. The DB file is created with [[Custom_local_repository_with_ABS_and_gensync|gensync]]. When you've got both, you can put them online (HTTP or FTP) and everyone will be able to use it by adding it as a regular repository.<br />
<br />
==developer==<br />
Half gods working to improve Arch for no financial gain. Developers are outranked only by our god, Judd Vinet.<br />
<br />
==devfs==<br />
The '''Dev'''ice '''F'''ile '''S'''ystem. DevFS handles, dynamically, the creation, deletion and permission management of device nodes in the /dev directory. It was the default kernel device manager in Arch Linux until release 0.7. Now DevFS is deprecated and in the process of being removed from the Linux kernel. DevFS has been superseded by [[udev]].<br />
<br />
Note that Arch installation CDs prior to 0.7.1 use the devfs naming scheme when creating /etc/fstab entries. See [[DevFS to Udev]].<br />
<br />
==/etc/network-profiles==<br />
In this, you can create various network configurations.<br />
<br />
This is very useful for laptop users that switch networks very often, for example between a home and an office network.<br />
<br />
Additionally it can be used with wpa-supplicant that can manage all of you wireless networks.<br />
For each configuration you need to make a configuration file. The easiest way to do this, is by copying the template.<br />
After you are done with this, you need to enable these in /etc/rc.conf<br />
<br />
After applying changes, you should restart your network by using, as root,<br />
/etc/rc.d/network restart<br />
<br />
==/etc/rc.conf==<br />
/etc/rc.conf is the main system configuration file for Arch Linux. It allows you to set your keyboard, timezone, hostname, network, daemons to run and modules to load at bootup, profiles, and more. Detailed description of the configuration options is given here: [[Rc.conf]]<br />
<br />
==/etc/rc.d==<br />
/etc/rc.d is a directory that contains the scripts that handle starting and stopping of services. On every boot, the services that are present in the DAEMONS= array in /etc/rc.conf are started by running the corresponding scripts in /etc/rc.d.<br />
<br />
It is also possible to control the services from the command line (as root), e.g.,<br />
<br />
/etc/rc.d/cups start<br />
<br />
would start the CUPS daemon. Typical arguments for the scripts are start, stop and restart.<br />
<br />
==/etc/rc.local==<br />
This script is run at the end of every boot. It is intended for miscellaneous commands that you might want to execute before the login prompt. It is not recommended to add any services or settings in /etc/rc.local that could be started or set from /etc/rc.conf instead.<br />
<br />
==extra/[extra]==<br />
Arch's official package set is fairly streamlined, but we supplement this with a larger, more complete "extra" repository that contains a lot of the stuff that never made it into our core package set. This repository is constantly growing with the help of packages submitted from our strong community.<br />
This is where desktop environments, window managers and common programs are found.<br />
<br />
==hotplug==<br />
==hwd==<br />
Hwd; hardware detect for Arch Linux, is for both devfs and udev device systems and also for kernels 2.4.x and 2.6.x. Instead of running an auto configure script what may be expected, Hwd (/usr/bin/hwd) doesn't change existing configures. Detects hardwares and modules, and provides information how to do manually. This allows the user to have a control over his/her system; basic philosophy of Arch Linux.<br />
<br />
Hwd is uploaded in Arch Linux's extra repository. To install, run pacman. <br />
<br />
pacman -S hwd<br />
<br />
here can you see the things you can use Hwd to [http://amlug.net/new-projects/hwd/hwd-46.jpg]<br />
<br />
==hwdetect==<br />
==initramfs==<br />
==initrd==<br />
The special file /dev/initrd is a read-only block device. Device /dev/initrd is a RAM disk that is initialized (e.g. loaded) by the boot loader before the kernel is started. The kernel then can use the block device /dev/initrd's contents for a two phased system boot-up.<br />
<br />
In the first boot-up phase, the kernel starts up and mounts an initial root file-system from the contents of /dev/initrd (e.g. RAM disk initialized by the boot loader). In the second phase, additional drivers or other modules are loaded from the initial root device's contents. After loading the additional modules, a new root file system (i.e. the normal root file system) is mounted from a different device.<br />
<br />
==makepkg==<br />
makepkg will build packages for you. makepkg will read the metadata required from a PKGBUILD file.<br />
All it needs is a build-capable linux platform, wget, and some build scripts. The advantage to a script-based build is that you only really do the work once. Once you have the build script for a package, you just need to run makepkg and it will do the rest: download and validate source files, check dependencies, configure the build time settings, build the package, install the package into a temporary root, make customizations, generate meta-info, and package the whole thing up for pacman to use.<br />
<br />
==namcap==<br />
namcap is a package analysis utility that looks for problems with ArchLinux packages or their PKGBUILD files. It can apply rules to the file list, the files themselves, or individual PKGBUILD files.<br />
<br />
Rules return lists of messages. Each message can be one of three types: error, warning, or information (think of them as notes or comments). Errors (designated by 'E:') are things that namcap is very sure are wrong and need to be fixed. Warnings (designated by 'W:') are things that namcap thinks should be changed but if you know what you're doing then you can leave them. Information (designated 'I:') are only shown when you use the info argument. Information messages give information that might be helpful but isn't anything that needs changing.<br />
<br />
==package==<br />
A package is an archive containing<br />
* all the (compiled) files of an application<br />
* metadata about the application, such as application name, version, dependencies, ...<br />
* installation files and directives for pacman<br />
* (optionally) extra files to make your life easier, such as a start/stop script<br />
Arch's package manager pacman can install, update and remove programs cleanly those packages. Using packages instead of compiling and installing programs yourself has various benefits:<br />
* easily updatable: pacman will update existing packages as soon as updates are available<br />
* dependency checks: pacman handles dependencies for you, you only need to specify the program and pacman installs it together with every other program it needs<br />
* clean removal: pacman has a list of every file in a package. This way no files are left behind when you decide to remove a package<br />
Note: different GNU/Linux distributions use different packages and package manager, meaning that you can't use pacman to install a Debian package on Arch.<br />
<br />
==pacman==<br />
The [[Pacman]] package manager is one of the great highlights of Arch Linux. It combines a simple binary package format with an easy-to-use build system (see ABS). Pacman makes it possible to easily manage and customize packages, whether they be from the official Arch repositories or the user's own creations. The repository system allows users to build and maintain their own custom package repositories, which encourages community growth and contribution (see AUR). <br />
<br />
Pacman can keep a system up to date by synchronizing package lists with the master server, making it a breeze for the security-conscious system administrator to maintain. This server/client model also allows you to download/install packages with a simple command, complete with all required dependencies (similar to Debian's apt-get). <br />
<br />
NB: Pacman was written and is being maintained by Judd Vinet, the creator of Arch Linux. It is used as a package management tool by other distros as well, such as FrugalWare (see also [[1]]), Rubix, UfficioZero (in Italian, based on Ubuntu), and, of course, ArchLinux-derivatives such as Archie and AEGIS.<br />
<br />
==pacman.conf==<br />
This is the configuration file of pacman. It's located in /etc. For a full explanation of its powers<br />
man pacman.conf<br />
<br />
==release/[release]==<br />
Release repository follows the semi-regular snapshot releases and does not update until the next snapshot/iso has been released. For example, the Release repository will point to all packages on the 0.5 ISO until we release 0.6; then it will point to 0.6 packages until 0.7 is released. This is useful if you only want to update your system when a new release is available.<br />
<br />
==repository/repo==<br />
The repository has the pre-compiled packages of one or (usually) more PKGBUILDs. Official repositories are<br />
* core: containing the latest version of packages required for a full CLI system<br />
* extra: containing the latest version of packages not needed for a working system, but needed for an enjoyable system ;)<br />
* community: containing packages that came from [http://aur.archlinux.org AUR] and got enough user votes<br />
Pacman uses these repositories to search for packages and install them. A repository can be local (i.e. on your own computer) or remote (i.e. the packages are downloaded before they're installed).<br />
<br />
==RTFM==<br />
'''R'''ead '''T'''he '''F'''ucking '''M'''anual. This simple message is replied to a lot of new linux/arch users who ask about the functionality of a program, when it is clearly defined in <pre>man program</pre><br />
<br />
It is often used when a user fails to make any attempt to find a solution to the problem themselves. If someone tells you this, they are not trying to offend you, they are just frustrated with your lack of effort. <br />
<br />
The best thing to do if you are told to do this, is to do as above, and read the manual page:<br />
<br />
* Read the program man page, at a command line<br />
man program-name<br />
* Search the wiki<br />
* Search the forum<br />
* Search the web<br />
<br />
==testing/[testing]==<br />
This is the repo where major packages/updates to packages are kept prior to release into the main repos, so they can be bug tested and upgrade issues can be found. It is disabled by default, but can be enabled in <code>/etc/pacman.conf</code><br />
<br />
==udev==<br />
udev provides a dynamic device directory containing only the files for actually present devices. It creates or removes device node files in the /dev directory, or it renames network interfaces.<br />
<br />
Usually udev runs as udevd(8) and receives uevents directly from the kernel if a device is added or removed form the system.<br />
<br />
If udev receives a device event, it matches its configured rules against the available device attributes provided in sysfs to identify the device. Rules that match, may provide additional device information or specify a device node name and multiple symlink names and instruct udev to run additional programs as part of the device event handling.<br />
<br />
==unstable/[unstable]==<br />
==versionpkg==<br />
This is a very simple script that allows you to easily update your CVS and SVN packages without having to edit the PKGBUILDs manually to enter the date or revision number. <br />
<br />
Simply run this script rather than makepkg in the build dir. This script completely removes the need for backtick execution to set the date or tag version in PKGBUILDs.<br />
<br />
More detailed information can be found [[Arch_CVS_%26_SVN_PKGBUILD_guidelines#versionpkg_-_a_makepkg_wrapper_for_CVS.2FSVN_builds|here]].<br />
<br />
==wiki==<br />
[[Main Page|This!]] A place to find documentation about ArchLinux. Anyone can add and modify the documentation.</div>Cengichttps://wiki.archlinux.org/index.php?title=User:Cengic&diff=35633User:Cengic2008-01-26T15:46:10Z<p>Cengic: /* Goran Cengic */</p>
<hr />
<div>Hi,<br />
<br />
My name is Goran Cengic and I'm a new Arch user switching from Slackware. I tried Arch several times before but it wasn't ready for me. Now when I'v tried it, it seems that it got a long way ahead. Nice clean init and easy text based confiuration for all major subsystems. I particularly like the use of the rc.conf and the design used for it. I also love the network profile system. I haven't seen anything as simple and useful in any other distro I have tried, and I have tried many :) <br />
<br />
I'v been using Linux since 1997 when I staretd out with Red Hat, moving on looking for the perfect distro until I found Slackware. I'v been Slack user for a decade now and I'm still using it on my desktop and workstation. The Arch is on my laptop since I'm spending more time on it nowdays.<br />
<br />
I'm looking forward to getting to know Arch better and being a part of the community.<br />
<br />
Regards.</div>Cengichttps://wiki.archlinux.org/index.php?title=User:Cengic&diff=35631User:Cengic2008-01-26T15:32:22Z<p>Cengic: </p>
<hr />
<div>= Goran Cengic =<br />
<br />
I'm a new Arch user switching from Slackware. I tried Arch several times before but it wasn't ready for me. Now when I'v tried it, it seems that it got a long way ahead. Nice clean init and easy text based confiuration for all major subsystems. I particularly like the use of the rc.conf and the design used for it. I also love the network profile system. I haven't seen anything as simple and useful in any other distro I have tried, and I have tried many :) <br />
<br />
I'v been using Linux since 1997 when I staretd out with Red Hat, moving on looking for the perfect distro until I found Slackware. I'v been Slack user for a decade now and I'm still using it on my desktop and workstation. The Arch is on my laptop since I'm spending more time on it nowdays.<br />
<br />
I'm looking forward to getting to know Arch better and being a part of the community.<br />
<br />
Regards.</div>Cengichttps://wiki.archlinux.org/index.php?title=User:Cengic&diff=35630User:Cengic2008-01-26T15:32:01Z<p>Cengic: </p>
<hr />
<div>= Goran Cengic =<br />
<br />
I'm a new Arch user switching from Slackware. I tried Arch several times before but it wasn't ready for me. Now when I'v tried it, it seems that it got a long way ahead. Nice clean init and easy text based confiuration for all major subsystems. I particularly like the use of the rc.conf and the design used for it. I also love the network profile system. I haven't seen anything as simple and useful in any other distro I have tried, and I have tried many :) <br />
<br />
I'v been using Linux since 1997 when I staretd out with Red Hat, moving on looking for the perfect distro until I found Slackware. I'v been Slack user for a decade now and I'm still using it on my desktop and workstation. The Arch is on my laptop since I'm spending more time on it nowdays.<br />
<br />
I'm looking forward to getting to now Arch a little better and being a part of the community.<br />
<br />
Regards.</div>Cengichttps://wiki.archlinux.org/index.php?title=User:Cengic&diff=35629User:Cengic2008-01-26T15:31:38Z<p>Cengic: New page: = Goran Cengic = I'm a new Arch user switching from Slackware. I tried Arch several times before but it wasn't ready for me. Now when I'v tried it, it seems that it got a long way ahead. ...</p>
<hr />
<div>= Goran Cengic =<br />
<br />
I'm a new Arch user switching from Slackware. I tried Arch several times before but it wasn't ready for me. Now when I'v tried it, it seems that it got a long way ahead. Nice clean init and easy text based confiuration for all major subsystems. I particularly like the use of the rc.conf and the design used for it. I also love the network profile system. I haven't seen anything as simple and useful in any other distro I have tried, and I have tried many :) <br />
<br />
I'v been using Linux since 1997 when I staretd out with Red Hat, moving on looking for the perfect distro until I found Slackware. I'v been Slack user for a decade now and I'm still using it on my desktop and workstation. The Arch is on my laptop since I'm spending more time on it nowdays.<br />
<br />
I'm looking forward to getting to now Arch a little better and being a part of the community.<br />
<br />
Regards,<br />
<br />
Goran</div>Cengichttps://wiki.archlinux.org/index.php?title=Talk:Mutualism_Arch&diff=35628Talk:Mutualism Arch2008-01-26T15:24:03Z<p>Cengic: </p>
<hr />
<div>What does "TU" abbreviation stand for? It is used in "What can I do..." section, "As experienced Arch Linux user..." subsection. I think we should spell out all abbreviations used in a page, at least once in the same page. This would make it easier for the new users (like me :) to get into the language used faster.<br />
<br />
Please remove that page now ;)<br />
We already have all terms described here:<br />
http://wiki.archlinux.org/index.php/Arch_Terminology/Jargon_for_newbies<br />
<br />
Heh, I was just about to create the page when I wanted to make sure that something like that doesn't already exist. So I found the Jargon_for_newbies (pretty obvious name :) and never made the abbreviations page. Thanks for the pointer anyway.</div>Cengichttps://wiki.archlinux.org/index.php?title=Talk:Mutualism_Arch&diff=35623Talk:Mutualism Arch2008-01-26T15:16:37Z<p>Cengic: </p>
<hr />
<div>What does "TU" abbreviation stand for? It is used in "What can I do..." section, "As experienced Arch Linux user..." subsection. I think we should spell out all abbreviations used in a page, at least once in the same page. This would make it easier for the new users (like me :) to get into the language used faster. I have started a new page [[Arch Abbreviations]] to kick this off.</div>Cengichttps://wiki.archlinux.org/index.php?title=Talk:Mutualism_Arch&diff=35622Talk:Mutualism Arch2008-01-26T15:15:47Z<p>Cengic: </p>
<hr />
<div>What does "TU" abbreviation stand for? It is used in "What can I do..." section, "As experienced Arch Linux user..." subsection. I think we should spell out all abbreviations used in a page, at least once in the same page. This would make it easier for the new users (like me :) to get into the language used faster. I have started a new page Arch_Abbreviations to kick this off.</div>Cengichttps://wiki.archlinux.org/index.php?title=Talk:Mutualism_Arch&diff=35620Talk:Mutualism Arch2008-01-26T15:13:20Z<p>Cengic: </p>
<hr />
<div>What does "TU" abbreviation stand for? It is used in "What can I do..." section, "As experienced Arch Linux user..." subsection. I think we should spell out all abbreviations used in a page, at least once in the same page.</div>Cengichttps://wiki.archlinux.org/index.php?title=Talk:Mutualism_Arch&diff=35617Talk:Mutualism Arch2008-01-26T15:12:17Z<p>Cengic: </p>
<hr />
<div>What does "TU" abbreviation stand for? It is used in "What can I do..." section, "As experienced Arch Linux user..." subsection. I think we should spell out all abbreviations used in a page at least once.</div>Cengichttps://wiki.archlinux.org/index.php?title=Talk:Mutualism_Arch&diff=35616Talk:Mutualism Arch2008-01-26T15:11:19Z<p>Cengic: </p>
<hr />
<div>What does TU abbreviation stand for? It is used in "What can I do..." section, "As experienced Arch Linux user..." subsection.</div>Cengichttps://wiki.archlinux.org/index.php?title=Talk:Mutualism_Arch&diff=35615Talk:Mutualism Arch2008-01-26T15:10:41Z<p>Cengic: New page: What does TU abbreviation stand for? It is used in "What can I do..." section, "as an experienced user..." subsection.</p>
<hr />
<div>What does TU abbreviation stand for? It is used in "What can I do..." section, "as an experienced user..." subsection.</div>Cengic