HTYP - User contributions [en]

Linux distributions

2008-08-29T07:12:24Z

Hagard: Undo revision 10270 by Special:Contributions/EnyaWcMhsaD (User talk:EnyaWcMhsaD)

==Navigation==
<section begin=navbar />{{#lst:Linux|navbar}}: [[Linux distributions|distros]]<section end=navbar />
==Overview==
[[Linux]] is available in many different flavors, each with different merits and weaknesses. There is no "official" version of Linux. The various flavors (or "[[distribution (software)|distribution]]s") each "[[fork (software)|fork]]" off from the original Unix sources at various different points; the details of this could form an article all by themselves.
==Reference==
* {{wikipedia|Linux distribution}}
==The List==
* [http://archlinux.org ArchLinux] ([http://wiki.archlinux.org/ wiki])
* [http://blagblagblag.org/ blag Linux and GNU]: "a single-cd distro with everything desktop users "expect" from a desktop, plus a collection of nice server apps." based on [[Fedora]]
* [http://www.centos.org/ CentOS]
* [http://damnsmalllinux.org/ Damn Small Linux] (DSL)
* [[Debian]] (http://debian.org/)
** [http://www.mepis.org/ Mepis]: includes [[ndiswrapper]]
** [http://knoppix.org/ Knoppix]: live CD only
*** [http://www.morphix.org/ Morphix] ([http://www.morphix.org/wiki/ wiki]): live CD with install (currently in beta)
** [[Ubuntu]]
* [[Fedora]] Core (formerly [[Red Hat Linux]])
* [http://www.gentoo.org/ Gentoo] ([http://gentoo-wiki.com/ unofficial wiki])
* [http://www.lunar-linux.org/ Lunar Linux]: user-customized kernel
* [http://slackware.com/ Slackware]
** [http://vectorlinux.com/ VectorLinux]
* [http://www.symphonyos.com/ SymphonyOS]
* [[SUSE]]
* [http://www.pclinuxos.com/ PCLinuxOS] (formerly [http://www.pclinuxonline.com/pclos/ PCLinux])

==Notes==
* Knoppix says it is Debian-based [http://www.knoppix.net/about.php here] (thanks, [[User:Tdcrone|Tim]]!)

VBA

2008-08-29T07:12:18Z

Hagard: Undo revision 10269 by Special:Contributions/EnyaWcMhsaD (User talk:EnyaWcMhsaD)

[[VBA]] stands for '''Visual Basic for Applications''', a version of Microsoft's [[Visual Basic]] designed specifically for the purpose of adding programming features to end-user applications. Its most popular use is in [[Microsoft Access]], where it is often used (for better or for worse) for business-critical data processing applications due largely to its very smooth integration with Access's data-handling user interface and the resulting intuitiveness it provides.
==Reference==
* {{wikipedia|Visual Basic for Applications}}

Manpages

2008-08-29T07:12:15Z

Hagard: Undo revision 10268 by Special:Contributions/EnyaWcMhsaD (User talk:EnyaWcMhsaD)

[[Category:Computer Terminology]]The term [[manpages]] usually refers to pages of documentation in the Unix and [[Linux]] operating systems, usually invoked with the [["man" command]].{{seed}}
==Related Articles==
* [[:Category:Manpages|Manpages]] category
==Reference==
* "Unix manual": {{wikipedia|Unix manual}}

The Arc of North Carolina

2008-08-29T07:12:11Z

Hagard: Undo revision 10267 by Special:Contributions/EnyaWcMhsaD (User talk:EnyaWcMhsaD)

==Navigation==
* {{#lst:North Carolina|navbar}}: [[The Arc of North Carolina|The Arc]][[category:US.NC]][[category:organizations]]
* The Arc: [[The Arc of the United States|United States]]: [[The Arc of North Carolina|North Carolina]]
==Overview==
{{seed}}
==Links==
===Official===
* [http://www.arcnc.org/ official web site]

dnsmasq.conf sample

2008-08-29T07:12:08Z

Hagard: Undo revision 10266 by Special:Contributions/EnyaWcMhsaD (User talk:EnyaWcMhsaD)

==Navigation==
[[computing]]: [[software]]: [[dnsmasq]]: [[dnsmasq.conf]]: [[dnsmasq.conf sample|sample]]
==Overview==
[[category:system files]]This is a sample of [[dnsmasq.conf]], mainly included because of all the comments. I'm stripping all the comments out of my actual file so I can see which lines are actually in use. This is a fairly basic configuration which uses [[/etc/hosts]] as well as having additional local-machinename definitions in a file called /etc/dnsmasqhosts.

==Contents==
# Configuration file for [[dnsmasq]].
#
# Format is one option per line, legal options are the same
# as the long options legal on the command line. See
# "/usr/sbin/dnsmasq --help" or "man 8 dnsmasq" for details.

# The following two options make you a better netizen, since they
# tell dnsmasq to filter out queries which the public DNS cannot
# answer, and which load the servers (especially the root servers)
# uneccessarily. If you have a dial-on-demand link they also stop
# these requests from bringing up the link uneccessarily.

# Never forward plain names (without a dot or domain part)
domain-needed
# Never forward addresses in the non-routed address spaces.
bogus-priv

# Uncomment this to filter useless windows-originated DNS requests
# which can trigger dial-on-demand links needlessly.
# Note that (amongst other things) this blocks all SRV requests,
# so don't use it if you use eg Kerberos.
# This option only affects forwarding, SRV records originating for
# dnsmasq (via srv-host= lines) are not suppressed by it.
#filterwin2k

# Change this line if you want dns to get its upstream servers from
# somewhere other that /etc/[[resolv.conf]]
#resolv-file=
resolv-file=/etc/dnsmasqupstreamservers

# By default, dnsmasq will send queries to any of the upstream
# servers it knows about and tries to favour servers to are known
# to be up. Uncommenting this forces dnsmasq to try each query
# with each server strictly in the order they appear in
# /etc/resolv.conf
#strict-order

# If you don't want dnsmasq to read /etc/resolv.conf or any other
# file, getting its servers from this file instead (see below), then
# uncomment this
#no-resolv

# If you don't want dnsmasq to poll /etc/resolv.conf or other resolv
# files for changes and re-read them then uncomment this.
#no-poll

# Add other name servers here, with domain specs if they are for
# non-public domains.
#server=/localnet/192.168.0.1
#server=166.70.63.3

# Add local-only domains here, queries in these domains are answered
# from /etc/hosts or DHCP only.
#local=/localnet/

# Add domains which you want to force to an IP address here.
# The example below send any host in doubleclick.net to a local
# webserver.
#address=/doubleclick.net/127.0.0.1

# If you want dnsmasq to change uid and gid to something other
# than the default, edit the following lines.
#user=
#group=

# If you want dnsmasq to listen for DHCP and DNS requests only on
# specified interfaces (and the loopback) give the name of the
# interface (eg eth0) here.
# Repeat the line for more than one interface.
#interface=
# Or you can specify which interface _not_ to listen on
#except-interface=
# Or which to listen on by address (remember to include 127.0.0.1 if
# you use this.)
#listen-address=
# If you want dnsmasq to provide only DNS service on an interface,
# configure it as shown above, and then use the following line to
# disable DHCP on it.
#no-dhcp-interface=

# On systems which support it, dnsmasq binds the wildcard address,
# even when it is listening on only some interfaces. It then discards
# requests that it shouldn't reply to. This has the advantage of
# working even when interfaces come and go and change address. If you
# want dnsmasq to really bind only the interfaces it is listening on,
# uncomment this option. About the only time you may need this is when
# running another nameserver on the same machine.
#bind-interfaces

# If you don't want dnsmasq to read /etc/hosts, uncomment the
# following line.
#no-hosts
# or if you want it to read another file, as well as /etc/hosts, use
# this.
#addn-hosts=/etc/banner_add_hosts
addn-hosts=/etc/dnsmasqhosts

# Set this (and domain: see below) if you want to have a domain
# automatically added to simple names in a hosts-file.
#expand-hosts

# Set the domain for dnsmasq. this is optional, but if it is set, it
# does the following things.
# 1) Allows DHCP hosts to have fully qualified domain names, as long
# as the domain part matches this setting.
# 2) Sets the "domain" DHCP option thereby potentially setting the
# domain of all systems configured by DHCP
# 3) Provides the domain part for "expand-hosts"
#domain=thekelleys.org.uk

# Uncomment this to enable the integrated DHCP server, you need
# to supply the range of addresses available for lease and optionally
# a lease time. If you have more than one network, you will need to
# repeat this for each network on which you want to supply DHCP
# service.
dhcp-range=192.168.0.50,192.168.0.150,12h

# This is an example of a DHCP range where the netmask is given. This
# is needed for networks we reach the dnsmasq DHCP server via a relay
# agent. If you don't know what a DHCP relay agent is, you probably
# don't need to worry about this.
#dhcp-range=192.168.0.50,192.168.0.150,255.255.255.0,12h

# This is an example of a DHCP range with a network-id, so that
# some DHCP options may be set only for this network.
#dhcp-range=red,192.168.0.50,192.168.0.150

# Supply parameters for specified hosts using DHCP. There are lots
# of valid alternatives, so we will give examples of each. Note that
# IP addresses DO NOT have to be in the range given above, they just
# need to be on the same network. The order of the parameters in these
# do not matter, it's permissble to give name,adddress and MAC in any order

# Always allocate the host with ethernet address 11:22:33:44:55:66
# The IP address 192.168.0.60
#dhcp-host=11:22:33:44:55:66,192.168.0.60

# Always set the name of the host with hardware address
# 11:22:33:44:55:66 to be "fred"
#dhcp-host=11:22:33:44:55:66,fred

# Always give the host with ethernet address 11:22:33:44:55:66
# the name fred and IP address 192.168.0.60 and lease time 45 minutes
#dhcp-host=11:22:33:44:55:66,fred,192.168.0.60,45m
dhcp-host=00:0e:2e:0d:44:be,Bunsen,192.168.0.106

# Give the machine which says it's name is "bert" IP address
# 192.168.0.70 and an infinite lease
#dhcp-host=bert,192.168.0.70,infinite

# Always give the host with client identifier 01:02:02:04
# the IP address 192.168.0.60
#dhcp-host=id:01:02:02:04,192.168.0.60

# Always give the host with client identifier "marjorie"
# the IP address 192.168.0.60
#dhcp-host=id:marjorie,192.168.0.60

# Enable the address given for "judge" in /etc/hosts
# to be given to a machine presenting the name "judge" when
# it asks for a DHCP lease.
#dhcp-host=judge

# Never offer DHCP service to a machine whose ethernet
# address is 11:22:33:44:55:66
#dhcp-host=11:22:33:44:55:66,ignore

# Ignore any client-id presented by the machine with ethernet
# address 11:22:33:44:55:66. This is useful to prevent a machine
# being treated differently when running under different OS's or
# between PXE boot and OS boot.
#dhcp-host=11:22:33:44:55:66,id:*

# Send extra options which are tagged as "red" to
# the machine with ethernet address 11:22:33:44:55:66
#dhcp-host=11:22:33:44:55:66,net:red

# Send extra options which are tagged as "red" to
# any machine with ethernet address starting 11:22:33:
#dhcp-host=11:22:33:*:*:*,net:red

# Send extra options which are tagged as "red" to any machine whose
# DHCP vendorclass string includes the substring "Linux"
#dhcp-vendorclass=red,Linux

# Send extra options which are tagged as "red" to any machine one
# of whose DHCP userclass strings includes the substring "accounts"
#dhcp-userclass=red,accounts

# If this line is uncommented, dnsmasq will read /etc/ethers and act
# on the ethernet-address/IP pairs found there just as if they had
# been given as --dhcp-host options. Useful if you keep
# MAC-address/host mappings there for other purposes.
#read-ethers

# Send options to hosts which ask for a DHCP lease.
# See RFC 2132 for details of available options.
# Note that all the common settings, such as netmask and
# broadcast address, DNS server and default route, are given
# sane defaults by dnsmasq. You very likely will not need any
# any dhcp-options. If you use Windows clients and Samba, there
# are some options which are recommended, they are detailed at the
# end of this section.
# For reference, the common options are:
# subnet mask - 1
# default router - 3
# DNS server - 6
# broadcast address - 28

# Set the NTP time server addresses to 192.168.0.4 and 10.10.0.5
#dhcp-option=42,192.168.0.4,10.10.0.5
dhcp-option=3,192.168.0.1

# Set the NTP time server address to be the same machine as
# is running dnsmasq
#dhcp-option=42,0.0.0.0

# Set the NIS domain name to "welly"
#dhcp-option=40,welly

# Set the default time-to-live to 50
#dhcp-option=23,50

# Set the "all subnets are local" flag
#dhcp-option=27,1

# Send the etherboot magic flag and then etherboot options (a string).
#dhcp-option=128,e4:45:74:68:00:00
#dhcp-option=129,NIC=eepro100

# Specify an option which will only be sent to the "red" network
# (see dhcp-range for the declaration of the "red" network)
#dhcp-option=red,42,192.168.1.1

# The following DHCP options set up dnsmasq in the same way as is specified
# for the ISC dhcpcd in
# http://www.samba.org/samba/ftp/docs/textdocs/DHCP-Server-Configuration.txt
# adapted for a typical dnsmasq installation where the host running
# dnsmasq is also the host running samba.
# you may want to uncomment them if you use Windows clients and Samba.
#dhcp-option=19,0 # option ip-forwarding off
#dhcp-option=44,0.0.0.0 # set netbios-over-TCP/IP nameserver(s) aka WINS server(s)
#dhcp-option=45,0.0.0.0 # netbios datagram distribution server
#dhcp-option=46,8 # netbios node type
#dhcp-option=47 # empty netbios scope.

# Send RFC-3397 DNS domain search DHCP option. WARNING: Your DHCP client
# probably doesn't support this......
#dhcp-option=119,eng.apple.com,marketing.apple.com

# Send encapsulated vendor-class specific options. The vendor-class
# is sent as DHCP option 60, and all the options marked with the
# vendor class are send encapsulated in DHCP option 43. The meaning of
# the options is defined by the vendor-class. This example sets the
# mtftp address to 0.0.0.0 for PXEClients
#dhcp-option=vendor:PXEClient,1,0.0.0.0

# Set the boot filename and tftpd server name and address
# for BOOTP. You will only need this is you want to
# boot machines over the network.
#dhcp-boot=/var/ftpd/pxelinux.0,boothost,192.168.0.3

# Set the limit on DHCP leases, the default is 150
#dhcp-lease-max=150

# The DHCP server needs somewhere on disk to keep its lease database.
# This defaults to a sane location, but if you want to change it, use
# the line below.
#dhcp-leasefile=/var/lib/misc/dnsmasq.leases

# Set the DHCP server to authoritative mode. In this mode it will barge in
# and take over the lease for any client which broadcasts on the network,
# whether it has a record of the lease or not. This avoids long timeouts
# when a machine wakes up on a new network. DO NOT enable this if there's
# the slighest chance that you might end up accidentally configuring a DHCP
# server for your campus/company accidentally. The ISC server uses the same
# the same option, and this URL provides more information:
# http://www.isc.org/index.pl?/sw/dhcp/authoritative.php
#dhcp-authoritative

# Set the cachesize here.
#cache-size=150

# If you want to disable negative caching, uncomment this.
#no-negcache

# Normally responses which come form /etc/hosts and the DHCP lease
# file have Time-To-Live set as zero, which conventionally means
# do not cache further. If you are happy to trade lower load on the
# server for potentially stale date, you can set a time-to-live (in
# seconds) here.
#local-ttl=

# If you want dnsmasq to detect attempts by Verisign to send queries
# to unregistered .com and .net hosts to its sitefinder service and
# have dnsmasq instead return the correct NXDOMAIN response, uncomment
# this line. You can add similar lines to do the same for other
# registries which have implemented wildcard A records.
#bogus-nxdomain=64.94.110.11

# If you want to fix up DNS results from upstream servers, use the
# alias option. This only works for IPv4.
# This alias makes a result of 1.2.3.4 appear as 5.6.7.8
#alias=1.2.3.4,5.6.7.8
# and this maps 1.2.3.x to 5.6.7.x
#alias=1.2.3.0,5.6.7.0,255.255.255.0

# Change these lines if you want dnsmasq to serve MX records.

# Return an MX record named "maildomain.com" with target
# servermachine.com and preference 50
#mx-host=maildomain.com,servermachine.com,50

# Set the default target for MX records created using the localmx option.
#mx-target=servermachine.com

# Return an MX record pointing to the mx-target for all local
# machines.
#localmx

# Return an MX record pointing to itself for all local machines.
#selfmx

# Change the following lines if you want dnsmasq to serve SRV
# records. These are useful if you want to serve ldap requests for
# Active Directory and other windows-originated DNS requests.
# See RFC 2782.
# You may add multiple srv-host lines.
# The fields are <name>,<target>,<port>,<priority>,<weight>
# If the domain part if missing from the name (so that is just has the
# service and protocol sections) then the domain given by the domain=
# config option is used. (Note that expand-hosts does not need to be
# set for this to work.)

# A SRV record sending LDAP for the example.com domain to
# ldapserver.example.com port 289
#srv-host=_ldap._tcp.example.com,ldapserver.example.com,389

# A SRV record sending LDAP for the example.com domain to
# ldapserver.example.com port 289 (using domain=)
#domain=example.com
#srv-host=_ldap._tcp,ldapserver.example.com,389

# Two SRV records for LDAP, each with different priorities
#srv-host=_ldap._tcp.example.com,ldapserver.example.com,389,1
#srv-host=_ldap._tcp.example.com,ldapserver.example.com,389,2

# A SRV record indicating that there is no LDAP server for the domain
# example.com
#srv-host=_ldap._tcp.example.com

# Change the following lines to enable dnsmasq to serve TXT records.
# These are used for things like SPF and zeroconf. (Note that the
# domain-name expansion done for SRV records _does_not
# occur for TXT records.)

#Example SPF.
#txt-record=example.com,v=spf1 a -all

#Example zeroconf
#txt-record=_http._tcp.example.com,name=value,paper=A4

# For debugging purposes, log each DNS query as it passes through
# dnsmasq.
#log-queries

# Include a another lot of configuration options.
#conf-file=/etc/dnsmasq.more.conf

udev

2008-08-29T07:12:05Z

Hagard: Undo revision 10265 by Special:Contributions/EnyaWcMhsaD (User talk:EnyaWcMhsaD)

==Navigation==
[[computing]]: [[software]]: [[Linux]]: [[udev]]
==Notes==
This text seemed like it might be useful information, even if it contained some inaccuracies. Original document was published under [http://www.gnu.org/licenses/gpl.html GNU General Public License, Version 2], and those with appropriate knowledge should feel free to edit or expand the text.

* [https://wiki.ubuntu.com/KubuntuIpod?highlight=%28mediamanager%29 KubuntuIpod] shows an example of udev usage
==Original Credits==
:This document is written by Daniel Drake <{{email|dan|reactivated|net}}>
:Please do not hesitate to send feedback!
:Copyright © 2003-2005 Daniel Drake
:This document is licensed under the GNU General Public License, Version 2.
==Edit Log==
* '''2005-10-05''' Copied from http://www.reactivated.net/writing_udev_rules.html, with minor editing for clarity. Probably needs considerable format editing.
==Text==
===Why?===
As stated above, writing rules for udev is an optional process. By default, you can plug a device in, and the a relevant node (e.g. /dev/sda for a mass-storage device) will be there, just like in previous /dev implementations.

However, udev allows you to customise the naming of device nodes. There are two reasons why you might want to do this: convenience, and persistent naming.

Take the example of using udev, so that when your printer is plugged in, it gets named as /dev/printer and also as the usual /dev/lp0. It's not only convenience (e.g. reading and interpreting "printer" as opposed to "lp0"), its a solution for non-persistent naming. Say that I have two printers - a HP laser printer and an Epson inkjet. When they are both plugged in and on, I have /dev/lp0 and /dev/lp1.

How do I know which node refers to which printer? There is no easy way. The first printer that got connected was assigned name "lp0", and the second "lp1". Plugging in my printers in a different order would swap the names here, and that would mess up my scripts that always expect my HP laser printer to be lp1.

However, if my HP laser printer got named lp_hp (as well as lpX) and my other printer got named lp_epson (as well as lpY), then my scripts could just refer to those names. udev magic can control this and ensure that these '''persistent names''' always point to the device that I intended.

For external mass-storage devices (e.g. usb hard disks), persistent naming is very helpful in that it allows you to hardcode accurate device paths into your /etc/[[fstab]].

It is important to understand that writing rules is simply a means of customizing udev behaviour. Writing rules is not a workaround for the problem where no device nodes for your particular device exist. If no matching rules exist, udev will create the node anyway, using the name that was supplied by the kernel.

===The basics of writing rules===
When populating /dev, udev decides which nodes to include, and how to name them, by reading a series of rules files.

Default udev rules are stored in /etc/udev/rules.d/50-udev.rules. You may find it interesting to look over this file - it includes a few examples, and then some default rules proving a devfs-style /dev layout. However, you should not write rules into this file directly, to reduce hassle while updating your udev installation in the future.

Files in /etc/udev/rules.d/ are parsed in '''lexical''' order. udev will stop processing rules as soon as it finds a matching rule in a file for the new item of hardware that has been detected. It is important that your own rules get processed before the udev defaults, otherwise your own naming schemes will not take effect! I suggest that you keep your own rules in a file at /etc/udev/rules.d/10-local.rules (this doesn't exist by default - create it). As 10 comes before 50, you know that your rules will be looked at first. It is important that the filenames of your rule files end with the '''.rules''' suffix, otherwise they will not be used.

As your own rules will effectively mask out the udev defaults which create the base /dev layout, it is recommended that you also specify devfs-style names/symlinks for the rules you write, so that you get the sensible defaults plus your own names.

In rule files, lines starting with a "#" are treated as comments. Every uncommented line in the file corresponds to a rule.

Rules are composed of keys. Keys are seperated by commas. Some keys are used for reading and matching information, others are used for assigning information and performing actions.

# At least one identification key should be provided, which will match the rule to any number of devices in the system. These are listed in the later section: [[#Identifying devices through basic keys]].
# At least one assignment key should be provided, to control how the resultant device node is created. These include NAME, SYMLINK, OWNER, GROUP and MODE, all of which are described in this document.

Common rules will use basic identification keys to determine the device to name, and then have a NAME assignement key to define the device node name. udev will only create one node for one device, so if you want it to be accessible through multiple nodes, then you have to specify the other nodes in the SYMLINK assignment key.

I'll take a slightly modified udev example rule to illustrate this:

BUS="usb", SYSFS{serial}="HXOLL0012202323480", NAME="lp_epson", SYMLINK="printers/epson_stylus"

The identification keys here are BUS and SYSFS{serial}. The assignment keys here are NAME and SYMLINK. udev will match this rule against a device that is connected through the USB bus and with a serial number of HXOLL0012202323480. '''Note that all (as opposed to any) specified keys must be matched for udev to use the rule to name a device.'''

udev will name this node lp_epson, and it will be located at /dev/lp_epson.

udev will also create a symlink to /dev/lp_epson, located at /dev/printers/epson_stylus (the printers directory will be automatically created). You can now print to your Epson printer by sending data to /dev/printers/epson_stylus or /dev/lp_epson.

Any rules that you have added or modified will '''not''' take effect until you notify udev of this. Make sure you remember to run the following every time you modify any rule files:

# udevstart

===Additional automated customisation for NAME and SYMLINK parameters===
In the NAME and SYMLINK parameters of your rules, you are able to use basic operators to assist the naming of devices. Hackers will know this sort of thing as ''[[printf]]-like string substitution''. There are a number of operators which can compose some or all of your NAME/SYMLINK parameters. These operators refer to kernel-data relating to the device. Take this example:

BUS="usb", SYSFS{vendor}="FUJIFILM", SYSFS{model}="M100", NAME="camera%n"

The %n operator will be replaced with the "kernel number" for the camera device, to produce a NAME such as camera0, camera1, etc.

Another common operator is %k. This represents what the kernel would name the device, e.g. "hda1". You may often see rules which have NAME="%k" to produce the default names for the hardware. In these rules, customisation is usually done through the SYMLINK parameter.

A full list of operators, with explanations, can be found in the udev man page.

===Using shell-style pattern matching in keys===
You can use shell style pattern matching to provide even more flexibility when writing keys. Taking a default udev rule:

KERNEL="ts*", NAME="input/%k"

The * operator is used here, which matches literally anything - zero, one, or more characters of any kind. The rule literally says:

{| width=80% align=center
|-
|Match a device identified by a KERNEL name starting with the letters "ts" optionally followed by anything at all, and name it with the KERNEL name (%k) under the input directory.
|}

The ? operator is similar, and matches any single character (but not zero characters).

You can also use square brackets [ ] to match any single character. Direct quote from udev man page:

{| width=80% align=center
|-
|For example, the pattern string "tty[SR]" would match either "ttyS" or "ttyR".
|}

You can also specify ranges that can be matched, e.g. [0-9] would match any single digit. Using an example rule from a default udev installation:

KERNEL="fd[0-9]*", NAME="floppy/%n"

This rule says:

{| width=80%
|-
|Match a device identified by a KERNEL name starting with the letters "fd", followed by any single digit, optionally followed by anything at all. Name the device with the kernel number of the device (%n) under the floppy directory.
|}

You can use these wildcards/pattern matches in any type of key, including both basic keys and sysfs-based identification (see below for explanations of these key types).

I have purposely left out some information on this topic (particularly the flexibility of using [ ] operators) that is out of the scope of basic rule-writing documentation. More information on this topic can be found in the udev man page.

===Key-writing basics===
udev provides a few basic key matching methods, and also provides flexible ways of matching information in SYSFS. A typical rule will match both normal keys (e.g. BUS and KERNEL), as well as SYSFS keys to differentiate between different hardware plugged in throught the same port.

You may be wondering, "How do I find the serial number of my printer? What is the model of my camera?". Rule writing isn't as hard as it sounds. The trickiest bit is finding your device in /sys, and deciding which info to use.

====Identifying devices through basic keys====
See the udev man page for more info on these keys.

The valid keys are:

* BUS - match the bus type of the device.
* KERNEL - match the kernel device name.
* DRIVER - match the name of the kernel driver.
* SUBSYSTEM - match the kernel subsystem name.
* ID - match the device number on the bus (e.g. PCI bus ID).
* PLACE - match the physical position where the device is plugged into (useful for USB).

The ID and PLACE keys do have their uses, but they are not commonly used in rules. This document focuses on using BUS and KERNEL keys, as well as SYSFS{...} keys (detailed in the next section). I will show how to use these keys by example.

For extra flexibility, udev also provides keys to call external scripts and examine their result, and to examine environment variables. This is out of scope of this document. Look at the udev man page for more details.

====Identifying devices through SYSFS files====
Background information: SYSFS stores many small files under a tree of directories which provide information about your hardware. One file typically contains just one "data item" - e.g. device name, manufacturer, or product ID.

Note that SYSFS{...} keys can be combined with the basic keys described in the previous section.

You can use keys in the format SYSFS{filename} to match specific info from SYSFS, where filename corresponds to a file in your SYSFS tree. For example, when my camera is connected, there is a file located at /sys/block/sda/device/model which contains "USB 2.0M DSC". To match this, I could use the following key: SYSFS{model} = "USB 2.0M DSC"

'''Note that any file in sysfs can be matched in this manner, but if you match more than one file (through multiple keys), then you must only match files that exist in the same directory.''' Typically, there will be several directories giving information about one device. You cannot mix and match (as shown by example below).

Luckily, the process of rule writing does not entail hunting through millions of files in SYSFS, the udevinfo utility does the hard work. This program is included in the udev distribution.

The first thing you need to do is find a directory somewhere in /sys that corresponds to your hardware, and includes a file named "dev", as udevinfo can only work on directories of this type. These directories are all found under either /sys/block or /sys/class - there is no point looking anywhere else! However, udevinfo will follow links through this directory and read info found from other sections of sysfs.

Once you have found a directory of this type, you can use the following command to assist you in the creation of writing keys for udev rules:

# udevinfo -a -p /sys/path/to/hardware/info

You may find that finding the correct place in /sys to run udevinfo on is not obvious. Chances are the device you just plugged in has already careted a device node (e.g. /dev/sda), in which case, udevinfo can be helpful! Taking the example of my /dev/sda node, running the following command will point you to the appropriate area of sysfs:

# udevinfo -q path -n /dev/sda

/block/sda

The output of the command (shown above) is telling me that the sysfs path to start at is /sys/block/sda. I would now run "udevinfo -a -p /sys/block/sda". These two commands can be chained together, like so:

# udevinfo -a -p $(udevinfo -q path -n /dev/sda)

Sidenote: You may notice that we previously provided full paths (/sys/some/path) to udevinfo beforehand, but now we are providing sysfs-relative paths (/some/path) by chaining these commands. This does not matter - both types of path are accepted.

Moving on to rule-writing, some snipped output of the results of my "udevinfo -a -p /sys/block/sda" command is shown below, with colour added.


follow the class device's "device"
looking at the device chain at '/sys/devices/pci0000:00/0000:00:02.1/usb3/3-3/3-3:1.0/host0/0:0:0:0':
BUS="scsi"
ID="0:0:0:0"
SYSFS{detach_state}="0"
SYSFS{type}="0"
SYSFS{max_sectors}="240"
SYSFS{device_blocked}="0"
SYSFS{queue_depth}="1"
SYSFS{scsi_level}="3"
SYSFS{vendor}=" "
SYSFS{model}="USB 2.0M DSC "
SYSFS{rev}="1.00"
SYSFS{online}="1"


looking at the device chain at '/sys/devices/pci0000:00/0000:00:02.1/usb3/3-3':
BUS="usb"
ID="3-3"
SYSFS{detach_state}="0"
SYSFS{bNumInterfaces}=" 1"
SYSFS{bConfigurationValue}="1"
SYSFS{bmAttributes}="c0"
SYSFS{bMaxPower}=" 0mA"
SYSFS{idVendor}="052b"
SYSFS{idProduct}="1514"
SYSFS{bcdDevice}="0100"
SYSFS{bDeviceClass}="00"
SYSFS{bDeviceSubClass}="00"
SYSFS{bDeviceProtocol}="00"
SYSFS{bNumConfigurations}="1"
SYSFS{speed}="12"
SYSFS{manufacturer}="Tekom Technologies, Inc"
SYSFS{product}="USB 2.0M DSC"


The udevinfo tool provides a lot of information which you can simply copy-paste as udev rules. The reason that I have colour coded the above output is to point out that '''you generally cannot mix and match information from different parts of the udevinfo output'''. In the above output, I could not combine information from the different coloured sections - this is because each section of output refers to a different directory in SYSFS. For example, the following rule would not work:

BUS="scsi", SYSFS{manufacturer}="Tekom Technologies, Inc", NAME="%k"

This rule would not work because I am combining information found in the section beginning with BUS="scsi" (green) with information only found in the blue section. The rule would work if I used BUS="usb", sticking only to information found in the blue section above.

You will notice that a lot of information is not relevant for writing basic rules (there is so much of it!), you should generally be looking for information that you recognise and know will not change (e.g. model name).

'''Note that if you write your own rule to identify a device, the default devfs-style rules will not take effect!''' It is usually sensible to use NAME="%k" and specify your own extra names in the SYMLINK parameter so that you do not lose the default sensible names.

I will show three examples of this rule writing based on udevinfo output process below. I will then attempt to list some device-dependant tips and tricks for locating the correct info.

A reader wrote to me and informed me that he found KDE's control centre useful for writing rules. Apparently, information about USB devices (and others) can be found in the "Info Centre" section of the KDE Control Centre. This interface shows information such as serial number, vendor ID, etc. If you prefer a GUI-like approach, you might want to investigate this.

The current releases of gnome-volume-manager are unable to treat symlink-nodes as real devices. Conversely as described above, you may wish to specify your own naming in the NAME parameter and specify %k in the SYMLINK parameter.

The behaviour of your own rules masking the defaults can be overcome if you write multiple-SYMLINK style rules.

===Using multiple SYMLINK style rules===
Another recent feature is the ability to write rules that do not specify a NAME, but instead they simply specify SYMLINK keys. This allows you to avoid the issue where your own rules effectively mask the udev defaults.

Take the rule:

KERNEL="hdc", SYMLINK="dvd"

When udev finds this rule, it will take a mental note of it. Upon finding another rule matching the same device which also includes a NAME parameter, udev will create the node as specified by the NAME parameter, plus symbolic links as specified by the SYMLINK parameters of both rules.
To put it into practical terms, when udev is naming nodes for my hdc device, it will use the default rules for block devices as usual, with the addition of my personal symlink "dvd".

Similarly to normal rules, rules of this type will only take effect if udev is able to find them before it finds a rule specifying a NAME parameter.

Controlling ownership and permissions
As well as controlling the naming of the device nodes which are created, udev rules also allow you to control ownership and permission attributes on that device node.

The GROUP key allows you to define which unix group should own the device node. Here's an example from the udev defaults, which defines that the video group will own framebuffer (fb) devices:

KERNEL="fb[0-9]*", NAME="fb/%n", SYMLINK="%k", GROUP="video"

The OWNER key, perhaps less useful, allows you to define which unix user should own the device node. Assuming the slightly odd situation where you would want "john" to own your floppy devices, you could use:

KERNEL="fd[0-9]*", OWNER="john"

You'll notice in the above rule that we didn't specify any NAME or SYMLINK keys. This is similar to the multiple symlink style where udev will take a mental note that we want john to own floppy nodes, and will apply that ownership once it finds a rule which defines a NAME for the floppy device nodes.

Building on the style mentioned above, you can do even more flashy things. The udev defaults use the following rule to define that all the sound device nodes shall be owned by the "audio" group:

SUBSYSTEM="sound", GROUP="audio"

This prevents the need to excessively provide a GROUP="audio" key on every following rule which names sound devices.

udev defaults to creating nodes with unix permissions of 0660 (read/write to owner and group), which is configured by the default_mode setting inside /etc/udev/udev.conf. There may be some situations where you do not want to use the default permissions on your device node. Fortunately, you can easily override the permissions in your rules using the MODE assignment key. As an example, the following rule defines that the inotify node shall be readable and writable to everyone:

KERNEL="inotify", NAME="misc/%k", SYMLINK="%k", MODE="0666"

Example: Writing a rule for my USB printer
After plugging in my printer, I started looking around some /sys directories for a relevant place to start. I didn't get anywhere, but I noticed that my printer had been given device node /dev/lp0. udevinfo was able to provide me with a useful path:

# udevinfo -q path -n /dev/lp0
/class/usb/lp0

Running "udevinfo -a -p /sys/class/usb/lp0" provided me with a heap of info, as usual. I picked out the relevant bits for unique device identification:

looking at the device chain at '/sys/devices/pci0000:00/0000:00:02.1/usb3/3-3':
BUS="usb"
SYSFS{manufacturer}="EPSON"
SYSFS{product}="USB Printer"
SYSFS{serial}="L72010011070626380"

My udev rule becomes:

BUS="usb", SYSFS{serial}="L72010011070626380", NAME="%k", SYMLINK="epson_680"

And my printer nodes exist at /dev/lp0 (or /dev/lp1 if another printer was plugged in beforehand) and /dev/epson_680 always points at the device node for that particular printer.

Example: Writing a rule for my USB-Storage digital camera
Quick Intro: My camera identifies itself as an external SCSI hard disk (it uses the usb-storage driver which is also used by devices such as USB hard disks and flash-card readers). I can then mount the partition on that disk and copy images over. Not all cameras work like this - many require external software (e.g. gphoto2) to be able to access photos.

This one is a bit tricky. Several nodes are created by default when my camera is connected : /dev/sda and /dev/sda1, and possibly even /dev/sg1. This is an example where specifity is important - if your rule is not specific enough, it could match any of the above 3 nodes.

sda1 is the node that I would like as my /dev/camera, as that is what gets mounted. udevinfo did not point out any useful differences between sda, sda1, and sg1. I decided that a reliable way to differentiate between these 3 nodes would be to look at the KERNEL name.

A key such as KERNEL="sd?1" would match KERNEL names such as "sda1", "sdb1", "sdc1", and equally importantly, it will not match KERNEL names such as sda, sdb, or sg1. The purpose of this key is to ignore the /dev/sda and /dev/sg1 nodes. The device is a digital camera - I would not dream of fdisking it or anything like that, so these 2 nodes are pretty useless to me. The key attempts to capture the /dev/sda1 node, which is mountable and therefore useful!

As this node (sda1) is treated as a block device, looking in /sys/block would be a good place to start.

In my /sys/block, I have a directory named sda. In my /sys/block/sda, I have a directory named sda1. Both of these directories have dev files in, so they are OK to run udevinfo on. Running the following dumps a lot of information about my camera and the USB port it is connected through.

# udevinfo -a -p /sys/block/sda/sda1

In the udevinfo output, I also noticed this bit of useful and understandable information:

SYSFS{product}="USB 2.0M DSC"

So that gives me my rule. For completeness, I also include a BUS key (this was also found in the udevinfo output).

BUS="usb", SYSFS{product}="USB 2.0M DSC", KERNEL="sd?1", NAME="%k", SYMLINK="camera"

Now, when my camera is plugged in, it will be named /dev/sda1 (or, if sda1 isnt available, it might be called /dev/sdb1) and will always be correctly linked to from /dev/camera. The /dev/sda (or sdb) node still appears as normal, but the important thing is that my custom persistent "camera" symlink points to the mountable partition.

Additional notes on writing rules for USB storage
Carl Streeter, the owner of a large USB hard disk, wrote to me and explained that unlike in my digital camera example, the /dev/sda node is useful to him. He pointed out that he does occasionally need to use tools such as fdisk and hdparm on that node.

Carl's rule is:

BUS="usb", KERNEL="sd*", SYSFS{product}="USB 2.0 Storage Device", NAME="%k", SYMLINK="usbhd%n"

This rule creates symlinks such as:

* /dev/usbhd - The fdiskable node
* /dev/usbhd1 - The first partition (mountable)
* /dev/usbhd2 - The second partition (mountable)

We agreed that depending on the situation and device in question, there are reasons for both wanting and not wanting the non-mountable /dev/sda node. Use whichever setup suits you best.

Another difficult situation is having a multiple-slot USB-storage card reader. These types of device generally do not inform the host when new cards are plugged in or out, so plugging a card into an unused slot while the reader is plugged in will not create the extra device node needed for mounting!
This problem also applies to other USB disks - e.g. if you create a new partition, the new partition node will not appear until you re-plug the device.

udev provides a solution here - it is able to create nodes for all partitions of a block device. For every rule that you specify, the block device will have all 16 partition nodes created. To achieve this, you can simply modify the NAME key, as shown below:

BUS="usb", SYSFS{product}="USB 2.0 Storage Device", NAME{all_partitions}="usbhd"

You will now have nodes named: usbhd, usbhd1, usbhd2, usbhd3, ..., usbhd15.

===Examples===
====Writing convenience rules for my CD drives====
I have two CD drives in my PC - a DVD reader, and a CD rewriter. My DVD is hdc and my CDRW is hdd. I would not expect this to change, unless I manually changed the cabling of my system.

Still, some people (myself included) like to have nodes such as /dev/dvd and /dev/cdrw for convenience. Since we know the "hdX" values for these drives, writing rules is simple. The examples below should be self explanatory.

BUS="ide", KERNEL="hdc", NAME="%k", SYMLINK="dvd cdroms/cdrom%n"
BUS="ide", KERNEL="hdd", NAME="%k", SYMLINK="cdrw cdroms/cdrom%n"

You may have noticed that the default 50-udev.rules file contains a rule which runs a script to produces names for block devices. Do not be confused by this - as usual, because your own rules are located in a file which is processed before the default rules, the defaults will not be used when naming the hardware you have written rules for.

====Writing a rule for your USB Visor Palm Pilot====
These devices work as USB-serial devices, so by default, you only get the ttyUSB1 node. The user-space palm utilities rely on /dev/pilot, so you need to use a rule to create this. The following rule will do the job:

BUS="usb", SYSFS{product}="Palm Handheld", KERNEL="ttyUSB*", SYMLINK="pilot"

This was adapted from Carsten Clasohm's blog entry, which includes a useful discussion of the situation. You may also wish to add ownership and permission keys to the rule to suit your setup.

====Writing a rule to name my network interface====
An interesting new feature in recent udev versions is the ability to rename your network interfaces, like the nameif utility does. Network interfaces do not show up in /dev, but they are generally referenced by names (e.g. with ifconfig). Despite the differences, the rule writing process is almost identical.

As usual, udevinfo comes to our aid in rule-writing. In my example, I wish to rename my "eth0" network device (the following output is snipped):

# udevinfo -a -p /sys/class/net/eth0/
looking at class device '/sys/class/net/eth0':
SYSFS{address}="00:52:8b:d5:04:48"

Every network adapter has its own unique MAC-address, so I chose to use this when writing my rule. This will not change, unless you change your network card. There is one caveat here: make sure you use the MAC address you obtain from udevinfo (as above), because it is case sensitive. Be careful when using utilities such as ifconfig as they will capitalize the letters.

An example rule is shown below:

KERNEL="eth*", SYSFS{address}="00:52:8b:d5:04:48", NAME="lan"

You will need to reload the net driver for this rule to take effect. You can either unload and reload the module, or simply reboot the system. You will also need to reconfigure your system to use "lan" rather than "eth0". I had some troubles getting this going (the interface wasn't being renamed) until I had completely dropped all references to eth0.
After that, you should be able to use "lan" instead of "eth0" in any calls to ifconfig or similar utilities.

===Tips for finding the appropriate places in SYSFS===
I'm looking for some more device specific tips here. Please contact me with any you can provide.

* If the device you are looking to write rules for has created a device node under /dev, then you are in luck! Run the following command to get an appropriate /sys path: udevinfo -q path -n /dev/yournode
* Always use udevinfo to assist the rule-writing process. Always use udevinfo to look under /sys/block or /sys/class (it will not start reading a chain from anywhere else).
* If you get totally stuck, use the following command to find all "dev" files under /sys (udevinfo can work on directories containing this file): find /sys -iname dev
* If your device is a flash-card reader, usb flash-drive, or digital camera that acts as usb-storage, that is created as /dev/sdX, then start looking in /sys/block/sdX.
* If applicable, make sure you identify the difference between sdX and sdX1 in the above situation. This can be done with the key KERNEL="sd?1" to match sdX1, or KERNEL="sd?" to match sdX.
* For USB printers that are created as /dev/lpX, then you should start looking in /sys/class/usb/lpX.
* The usb scanner driver has recently been removed from the kernel and re-implemented in userspace (as part of the SANE package). You do not (and can not) write rules for this hardware as it does not rely on specific kernel drivers.
* Remember that unfortunately, the kernel does not export information for all devices into sysfs, meaning that you simply can't write rules for some devices yet. On 20/02/04, the udev author stated that there are 162 drivers left to convert to sysfs.

===Debugging your rules===
If you have written rules and remembered to run udevstart but they do not appear to be taking effect, there are a couple of ways you can debug them.

The file /etc/udev/udev.conf contains a udev_log option. Setting this option to yes will cause udev to log some useful information about which rules are being applied to which nodes into the system logger. The logs will be included in /var/log/messages for most users.

Additionally, if you know the path in sysfs for the node you want to create, you can use udevtest to see a rundown on what udev would do with the node. For example:

# udevtest /sys/class/sound/dsp/
version 056
looking at '/class/sound/dsp/'
opened class_dev->name='dsp'
configured rule in '/etc/udev/rules.d/50-udev.rules[132]' applied, added symlink '%k'
configured rule in '/etc/udev/rules.d/50-udev.rules[132]' applied, 'dsp' becomes 'sound/%k'
creating device node '/dev/sound/dsp', major = '14', minor = '3', mode = '0660', uid = '0', gid = '18'

udevtest is only a debugging/testing tool - it does not actually create the device node, even though it says it doing so!

Dallas, TX

2008-08-29T07:11:57Z

Hagard: Undo revision 10264 by Special:Contributions/EnyaWcMhsaD (User talk:EnyaWcMhsaD)

==Navigation==
{{US Town|Dallas|Texas|TX}}{{seed}}
==Directory==
* [http://www.dallasobserver.com/ The Dallas Observer]

SanMar

2008-08-29T07:11:53Z

Hagard: Undo revision 10263 by Special:Contributions/EnyaWcMhsaD (User talk:EnyaWcMhsaD)

[[Category:Businesses]][[SanMar]] is a family-owned supplier of apparel located in [[Prestin, WA]]. They incorporated in 1971.{{seed}}
SanMar has created a number of private labels:
* [http://www.districtthreads.com District Threads]
* [http://www.sporttekusa.com Sport-Tek] by Port Authority
* [http://www.portandcompany.com Port Authority Clothing] ([http://www.portauthorityclothing.com alt])
==Reference==
* [http://www.sanmar.com company web site]
* [http://www.careerbuilder.com/JobSeeker/Companies/CompanyDetails.aspx?Comp_DID=C8F7DX6R579WJ3M5S8G careerBuilder]

919-357-2554

2008-08-29T07:11:50Z

Hagard: Undo revision 10262 by Special:Contributions/EnyaWcMhsaD (User talk:EnyaWcMhsaD)

[[Category:phone numbers]][[Category:unwanted calls]]
* 2006-01-27 Called {{harena}}'s cellphone, left no message

Gatlinburg, TN

2008-08-29T07:11:28Z

Hagard: Undo revision 10261 by Special:Contributions/EnyaWcMhsaD (User talk:EnyaWcMhsaD)

=={{hide|navbar}}==
{{US Town|Gatlinburg|Tennessee|TN}}{{seed}}
==Reference==
* {{wikipedia|Gatlinburg, Tennessee}}
* {{wikitravel|Gatlinburg}}
==Directory==
===Events===
* [http://www.smokymtngiftshow.com/ Smoky Mountain Gift Show]: semi-annual trade show
** [http://tradeshow.alibaba.com/trade_shows/342766/The_Smoky_Mountain_Gift_Show_Fall.html listing] at Alibaba.com
===Lodging===
* [http://crownparkgetaways.com/ Crown Park Resort] (owned by [[Burroughs & Chapin]])

GNU FDL

2008-08-29T07:11:24Z

Hagard: Undo revision 10260 by Special:Contributions/EnyaWcMhsaD (User talk:EnyaWcMhsaD)

==Overview==
The GNU Free Documentation License, or [[GNU FDL]], is an [[intellectual property license]] specifically designed for written material that is intended to be freely available. It is the counterpart of the [[GNU GPL]], which provides a similar license for [[software]].

The license requires, in general, that those who copy the licensed material must in turn make that material freely available under the same license ''and'' must also provide a copy of that license along with the material. (In the case of web-hosted material, a link to a web page containing the license is sufficient.)

Because most IP licenses are intended to protect the owner's copyright by ''preventing'' copying, the GNU FDL (which ''encourages'' copying) is often referred to as a "copyleft" license.

The contents of [[Wikipedia]] and [[HTYP]] are provided under the GNU FDL.
==Links==
===Reference===
* {{wikipedia|GNU Free Documentation License}}
* [http://www.gnu.org/copyleft/fdl.html official page] at gnu.org

MediaWiki/archive/customizing/URLs/error handlers

2008-08-29T07:11:21Z

Hagard: Undo revision 10259 by Special:Contributions/EnyaWcMhsaD (User talk:EnyaWcMhsaD)

==Navigation==
{{web software|MediaWiki}}: [[MediaWiki customization|customization]]: [[shortening MediaWiki URLs]]: [[using error handlers to tidy MediaWiki URLs|using error handlers]]{{sidebar|__TOC__}}
==Overview==
These methods set up the Apache web server so that MediaWiki pages are loaded in response to requests for pages which the web server sees as unavailable. Custom code extracts the page name from the request information, and calls MediaWiki functions to display the requested page.

I don't know of any particular circumstances where this would work and the recommended mod_rewrite method would not; this documentation is now considered obsolete, but is being kept here in case it is useful.

'''Potential problem''': use [[wget]] to make sure that pages are not actually returning an error code (404 or 403), which apparently prevents some browsers (e.g. [[Microsoft Internet Explorer|MSIE]]) from viewing them under some circumstances, and will certainly adversely affect search-engine listings.
==Using a 404 Handler==
''At this point, I can't recommend this method unless nothing else works. If you try this method, please report back on how it goes. --[[User:Woozle|Woozle]] 18:46, 29 June 2006 (EDT)''

This uses the 404 (missing page) redirect mechanism – a standard /index.php/ request is handled by the standard code (in index.php), but any other URL which doesn't correspond to an existing page (within the wiki or not) is handled by a modified index.php. For any given "nonexistent" URL of the form "<nowiki>http://yourdomain.com/nonexistent/page</nowiki>", the code returns a wiki page entitled "Nonexistent/page", with the "nonexistent" URL displayed as the URL for that page.

There is also a feature wherein you can create a page called [[Mediawiki:your/url/here]] and it will redirect to an article whose title is the ''contents'' of that page. For example: http://wiki.vbz.net/Currentevents is redirected to [[vbzwiki:Current events]] because the page [[vbzwiki:MediaWiki:Currentevents]] contains the text "Current events". (This is a bit of a trivial trick, as you can accomplish almost the same thing using #redirect pages.)

'''First''', in the main [[.htaccess]] file (or in httpd.conf if you prefer), assign a location to handle 404 errors such that a PHP file will be loaded -- either of these will do, for example:
<pre>
ErrorDocument 404 /errors/404/
ErrorDocument 404 /wiki404error.php
</pre>
In the first instance, your modified index.php file would go in /errors/404/; in the second, it would be renamed wiki4040error.php and go in the same folder as the normal index.php.

The remaining instructions depend on which MediaWiki version you are using.
===Version 1.4===
''These instructions were made from changes that actually worked, but I may have left out some steps. I was more careful when I did the changes for version 1.5, so if these don't work check the version 1.5 instructions for anything missing.''

'''Second''': Make the changes indicated in the 404-handling copy of index.php:
<pre>
if ( '' == $title && 'delete' != $action ) {
## 2005-06-19 Woozle mods for "missing" page
# title not passed in parameter; use REQUEST_URI from environment
$title = rawurldecode(ltrim($_SERVER['REQUEST_URI'], " /"));
# see if there's a page designated for this URI
$wgTitle = Title::newFromText( wfMsgForContent( $title ) );
if ('' == $wgTitle) {
$wgTitle = Title::newFromText( $title );
}
## end Woozle mods
} elseif ( $curid = $wgRequest->getInt( 'curid' ) ) {
</pre>

<pre>
/* redirect to canonical url, make it a 301 to allow caching */
$wgOut->setSquidMaxage( 1200 );
# 2005-06-21 Woozle mods to allow 404 page to summon wiki page without redirecting
# $wgOut->redirect( $wgTitle->getFullURL(), '301');
$wgArticle = new Article( $wgTitle );
# $mainText = $wgOut->parse( $wgArticle->getContent( false ) );
# echo $mainText;
$wgArticle->view();
# end Woozle mods
} else if ( Namespace::getSpecial() == $wgTitle->getNamespace() ) {
</pre>

===Version 1.5===
'''Second''': In the same folder as the modified index.php, create a LocalSettings.php with the following contents:
<?php
require_once( "../../LocalSettings.php" );

$wgScript = $wgScriptPath;
$wgArticlePath = "$wgScript/$1";
?>

Note: "../../LocalSettings.php" works if your modified index.php is buried two folders deep from your main index.php (as in the /errors/404/index.php example); adjust it as needed to point to your main LocalSettings.php.

'''Third''': Make the changes indicated in the 404-handling copy of index.php:

* First change - need to point to the copied Defines.php:
<pre>
# 2005-10-25 Woozle - for 404 handling
require_once( './Defines.php' );
</pre>

* Second change - this is optional, but it cleans up the file a lot:
<pre>
# 2005-10-25 Woozle - config code removed because it will never be executed
#if( !file_exists( 'LocalSettings.php' ) ) {
# ...
#}
</pre>

* Third change - this pulls in the title-request from the error URI:
# Query string fields
# 2005-10-25 Woozle - 404 support - parameters have to be parsed from $_SERVER instead of $_REQUEST
$raw_uri = rawurldecode(ltrim($_SERVER['REQUEST_URI'], " /"));
$arr_uri = explode('?',$raw_uri);
$title = $arr_uri[0];
$uri_qry= $arr_uri[1];
parse_str($uri_qry,$_REQUEST);
$action = $wgRequest->getVal( 'action', 'view' );
$title_force = $wgRequest->getVal( 'title' );
if ('' != $title_force) {
$title = $title_force;
}
# 2005-10-25 END

* Fourth change - optional and untested - allow title redirection
if ( '' == $title && 'delete' != $action ) {
$wgTitle = Title::newFromText( wfMsgForContent( 'mainpage' ) );
# 2005-10-26 Woozle - 404 support - optional redirect based on "mediawiki:articlename"
if ('' == $wgTitle) {
$wgTitle = Title::newFromText( $title );
}
# 2005-10-26 END

* Fifth change - I'm actually not sure if this is necessary, but don't have time to test uncommenting it:
# 2005-10-25 Woozle - for 404 handling - block out redirection code
# was -- if ((action is explicitly "view") AND (title is not passed as param) OR (title is not in canonical form) AND ??
#} else if ( ( $action == 'view' ) && (!isset( $_GET['title'] ) || $wgTitle->getPrefixedDBKey() != $_GET['title'] ) && !count( array_diff( array_keys( $_GET ), array( 'action', 'title' ) ) ) )
#{
# /* redirect to canonical url, make it a 301 to allow caching */
# $wgOut->setSquidMaxage( 1200 );
# $wgOut->redirect( $wgTitle->getFullURL(), '301');
} else if ( NS_SPECIAL == $wgTitle->getNamespace() ) {
===Finally===
Finally, put the modified index.php where it will be the page used to handle 404 errors.

* '''Caveats''':
** Your arbitrary URL will have its first character capitalized before it is displayed as the page's title or used to load another page (if you have set up a Mediawiki: page for it), although the URL shown will remain unchanged
** There is probably a lot of excess index.php code which can be stripped out, as it will never be executed in this context
** URLs ending in slashes appear to be a problem for some namespaces; the wiki code appears to be reading the URL from some place other than the modified code. (This doesn't seem to be a problem for version 1.5.)
** <s>All wiki links on the loaded page will point back to canonical wiki URLs, e.g. http://htyp.org/wiki/index.php/Main_Page; to change this. see "Shortening the links" below.</s> 2006-02-16 This has been fixed.
** <s>Image thumbnail links don't work.</s> 2006-02-16 This has been fixed.
* '''2006-02-16''' Notes:
** I changed the procedure a bit and page viewing now seems to work consistently, but I've only checked a few pages for proper behavior. Please test thoroughly before using on a production page, and let me know what you find.
** '''Editing does not work properly'''
** If certain pages persist in showing old-style links, they may be cached; add "?action=purge" to the URL to clear the cache for a given page. If you are working on an active site using the old-style links, some pages may mysteriously revert to old-style links as visitors browse them through the old-style portal, causing the old-style to be re-cached.
** This method is probably not very compatible with most webstats generators, but I haven't tried it long enough to see what happens. Probably all pages will be logged as 404 errors, which isn't terribly useful.

'''Note about CPU load''': Obviously it has to do the same URL translation it would normally have to do and then determine that the file doesn't exist, but that shouldn't take any more cycles than locating an existing file; for URLs containing at least one slash, it should be quicker. Given all the processing done by the MediaWiki software for loading "normal" wiki pages, I suspect the difference is negligible.

==Using a 403 [forbidden] Handler==
{{anonusersig|64.110.252.116}} reports: Something I have found to work very well is to force all files except index.php to "Deny from All" and use a 403 error handler to push all requests to index.php:

An example .htaccess:
Deny from All
<Files "index.php">
Allow from All
</Files>
# NOTE: DirectoryIndex may not be necessary
DirectoryIndex index.php
ErrorDocument 403 /index.php

This could probably be shortened up, but I have found it works great. :-) {{anonusersig|64.110.252.116}}

This would seem to be a variation on the 404 method above; not sure if there are any advantages or disadvantages to either one.

LibertyNames

2008-08-29T07:11:10Z

Hagard: Undo revision 10258 by Special:Contributions/EnyaWcMhsaD (User talk:EnyaWcMhsaD)

[[Category:Businesses]]
==Opinions==
===[[User:Woozle|Woozle]] 07:59, 8 May 2005 (CDT)===
"[[LibertyNames]] of America" is a [[Domain Registrar]] known for sending out domain registration transfer offers heavily disguised as renewal notices, therefore qualifying as a [[Domain Registration Cuckoos|Domain Registration Cuckoo]]. Their prices are slightly better than those of [[Ilscorp.net]], and to their credit they do include some useful services like DNS. However, the practice of sending out bogus renewal notices is a big black mark against them, and the services they offer are available for much less from other more reputable registrars.

'''Rating:''' Avoid
==Links==
* [http://lnoa.com LibertyNames of America] official web site
==Related Articles==
*[[Domain Registration Cuckoos]]

groupware

2008-08-29T07:11:07Z

Hagard: Undo revision 10257 by Special:Contributions/EnyaWcMhsaD (User talk:EnyaWcMhsaD)

==Navigation==
[[computing]]: [[software]]: [[groupware]]
==Overview==
The term [[groupware]] refers to software intended to help a group work together more productively. Such software is known more generically as "collaborative software".
==Related Pages==
* [[Wiki]] software is a particular type of [[groupware]].
==Groupware Suites==
All software listed is [[free and open source]] unless otherwise specified.
* [http://www.egroupware.org/ eGroupWare]
==Links==
===Reference===
* {{wikipedia|Collaborative software}}

CPSC Plans Announcement

2008-08-29T07:11:04Z

Hagard: Undo revision 10256 by Special:Contributions/EnyaWcMhsaD (User talk:EnyaWcMhsaD)

[[Central Park School for Children]] Plans Announcement (half-page notice sent home with kids 2006-01-09)
==Text==
Happy New Year Central Park Families!

We are making plans about our work that we'd like to share. As a staff we have spent time reflecting on some school practices and looking at ways we can make learning more enriching. Here are a few of the practices we want to broaden to give students a stronger foundation.
* '''Assemblies''' – To showcase more of what students are learning, and introduce routines and procedures for the whole school
* '''Conflict-resolution groups''' – Teaching all children how to resolve differences verbally
* '''Lunch Program''' – Open to all families (TBA)
* '''School Newspaper''' – Students will produce, school-wide
* '''Cross grade level projects''' such as peer buddies, book buddies and mentors
* '''School-wide exhibits / Special enrichment projects''' – Science exhibits
* '''Standardizing portfolios''' – Looking at what we include as assessment for each student
* As a staff, we are committed to ongoing staff development on project-based learning, conflict resolution, developmental reading assessment and differential instruction.

We appreciate your patience and co-operation as we educate ourselves to better educate your children.

We appreciate all of your volunteer hours and constructive feedback to help us grow.

Sincerely, 
Carolyn

Winston-Salem, NC

2008-08-29T07:11:00Z

Hagard: Undo revision 10255 by Special:Contributions/EnyaWcMhsaD (User talk:EnyaWcMhsaD)

{{US Town|Winston-Salem|North Carolina|NC}}{{seed}}
*'''Part of:''' [[The Triad, NC|The Triad]], [[Forsyth County, NC|Forsyth County]]
==Reference==
* [http://www.epodunk.com/cgi-bin/genInfo.php?locIndex=19771 ePodunk]
* {{wikipedia|Winston-Salem, North Carolina}}
==Topics==

Cardservice International

2008-08-29T07:10:56Z

Hagard: Undo revision 10254 by Special:Contributions/EnyaWcMhsaD (User talk:EnyaWcMhsaD)

==Navigation==
[[business]]: [[merchant card processing]]: [[Cardservice International]]{{seed}}
==Overview==
[[category:businesses]][[Cardservice International]] provides merchant processing of credit and debit cards ([[merchant card processing]]) including [[Visa]], [[MasterCard]], [[Discover Card]], [[American Express]], and [[Diner's Club]].
==Reviews==
* [[Htwiki:Cardservice International|Cardservice International]]: Woozle's review on the HypertWiki
==Links==
* [http://cardservice.com/ CardService International] main web site
** [http://mymerchantoffice.com MyMerchantOffice]: account management site (i.e. if you use Cardservice, this is where you manage your account)

.mp3

2008-08-29T07:10:39Z

Hagard: Undo revision 10252 by Special:Contributions/EnyaWcMhsaD (User talk:EnyaWcMhsaD)

[[.mp3]] is the most common [[file extension]] used for [[MPEG Layer 3]] audio files.

BitTorrent

2008-08-29T07:10:36Z

Hagard: Undo revision 10253 by Special:Contributions/EnyaWcMhsaD (User talk:EnyaWcMhsaD)

[[category:computer terminology]][[BitTorrent]] is both the name of a [[BitTorrent (system)|file sharing system]] and the [[BitTorrent (client)|software]] which first implemented it.

By default, it refers to the [[BitTorrent (system)|system]], which includes both the BitTorrent [[protocol]], the [[.torrent]] file format, the [[torrent tracker]] (server for tracking torrent connections), and possibly other elements. The term "torrent" is often used as shorthand for the files downloaded via the BitTorrent protocol; the act of either uploading or downloading such files (which usually happen simultaneously to a certain extent, due to the nature of the system) is often called "torrenting".
==Links==
* {{wikipedia}}

Emerald Isle, NC

2008-08-29T07:08:52Z

Hagard: Undo revision 10271 by Special:Contributions/EnyaWcMhsaD (User talk:EnyaWcMhsaD)

==Navigation==
{{US Town|Emerald Isle|North Carolina|NC}}
* '''Part of''': [[Bogue Banks]], [[NC shore]]
* '''Next to''':
** '''Towns''': (Southwest) {{townlink|Ocean Crest|NC}}, (Northeast) {{townlink|Indian Beach|NC|}}
** '''Natural''': [[Atlantic Ocean]]
==Topics==
===Issues===
* '''2005-08-17''': [http://www.indyweek.com/durham/2005-08-17/cover.html beach "renourishment"] (Independent Weekly)
{{seed}}