text:
LPI Linux Certification/Advanced Network Configuration & Troubleshooting

Detailed Objective (205.2)
(LPIC-2 Version 4.5)

Weight: 4

Description: Candidates should be able to configure a network device to implement various network authentication schemes. This objective includes configuring a multi-homed network device and resolving communication problems.

Key Knowledge Areas:
 * Utilities to manipulate routing tables
 * Utilities to configure and manipulate ethernet network interfaces
 * Utilities to analyse the status of the network devices
 * Utilities to monitor and analyse the TCP/IP traffic

Terms and Utilities:

Overview
Description: ''The candidate should be able to configure a network device to implement various network authentication schemes. This objective includes configuring a multi-homed network device, configuring a virtual private network and resolving networking and communication problems.''

Key files, terms, and utilities include:

/sbin/route /sbin/ifconfig /bin/netstat /bin/ping /sbin/arp /usr/sbin/tcpdump /usr/sbin/lsof /usr/bin/nc

Network packet filtering
Network packet filtering is done in one of three ways under Linux : Their design and capabilities are quite different – note that ipfwadm is considered obsolete, iptables being the most advanced and current In iptables, the packet flow diagram looks like :
 * Ipfwadm : kernel 2.0.x and up (RedHat 5.x)
 * Ipchains : kernel 2.2.x and up (RedHat 6.x, 7.0)
 * Iptables : kernel 2.4.x and up (RedHat 7.1 – 9.0)

Iptables need some options configured in your kernel (or as modules) :

 * CONFIG_PACKET : This option allows applications and utilities that needs to work directly to various network devices. Examples of such utilities are tcpdump or snort.

 * CONFIG_NETFILTER : This option is required if you're going to use your computer as a firewall or gateway to the Internet.

 * CONFIG_IP_NF_CONNTRACK : This module is needed to make connection tracking. Connection tracking is used by, among other things, NAT and Masquerading. If you need to firewall machines on a LAN you most definitely should mark this option.

 * CONFIG_IP_NF_FTP : This module is required if you want to do connection tracking on FTP connections. Since FTP connections are quite hard to do connection tracking on in normal cases, conntrack needs a so called helper, this option compiles the helper. If you do not add this module you won't be able to FTP through a firewall or gateway properly.

 * CONFIG_IP_NF_IPTABLES : This option is required if you want do any kind of filtering, masquerading or NAT. It adds the whole iptables identification framework to the kernel. Without this you won't be able to do anything at all with iptables.

 * CONFIG_IP_NF_MATCH_LIMIT : This module isn't exactly required. This option provides the LIMIT match, that adds the possibility to control how many packets per minute that are to be matched, governed by an appropriate rule. For example, -m limit --limit 3/minute would match a maximum of 3 packets per minute. This module can also be used to avoid certain Denial of Service attacks.

 * CONFIG_IP_NF_MATCH_MAC : This allows us to match packets based on MAC addresses. Every Ethernet adapter has its own MAC address. We could for instance block packets based on what MAC address is used and block a certain computer pretty well since the MAC address very seldom change.

 * CONFIG_IP_NF_MATCH_MARK : This allows us to use a MARK match. For example, if we use the target MARK we could mark a packet and then depending on if this packet is marked further on in the table, we can match based on this mark. This option is the actual match MARK, and further down we will describe the actual target MARK.

 * CONFIG_IP_NF_MATCH_MULTIPORT : This module allows us to match packets with a whole range of destination ports or source ports. Normally this wouldn't be possible, but with this match it is.

 * CONFIG_IP_NF_MATCH_TOS : With this match we can match packets based on their TOS field. TOS stands for Type Of Service. TOS can also be set by certain rules in the mangle table and via the ip/tc commands.

 * CONFIG_IP_NF_MATCH_TCPMSS : This option adds the possibility for us to match TCP packets based on their MSS field.

 * CONFIG_IP_NF_MATCH_STATE : This is one of the biggest news in comparison to ipchains. With this module we can do stateful matching on packets. For example, if we have already seen traffic in two directions in a TCP connection, this packet will be counted as ESTABLISHED.

 * CONFIG_IP_NF_MATCH_UNCLEAN : This module will add the possibility for us to match IP, TCP, UDP and ICMP packets that don't conform to type or are invalid. We could for example drop these packets, but we never know if they are legitimate or not. Note that this match is still experimental and might not work perfectly in all cases.
 * CONFIG_IP_NF_MATCH_OWNER : This option will add the possibility for us to do matching based on the owner of a socket. For example, we can allow only the user root to have Internet access. This module was originally just written as an example on what could be done with the new iptables. Note that this match is still experimental and might not work for everyone.

 * CONFIG_IP_NF_FILTER : This module will add the basic filter table which will enable you to do IP filtering at all. In the filter table you'll find the INPUT, FORWARD and OUTPUT chains. This module is required if you plan to do any kind of filtering on packets that you receive and send.

 * CONFIG_IP_NF_TARGET_REJECT : This target allows us to specify that an ICMP error message should be sent in reply to incoming packets, instead of plainly dropping them dead to the floor. Keep in mind that TCP connections, as opposed to ICMP and UDP, are always reset or refused with a TCP RST packet.

 * CONFIG_IP_NF_TARGET_MIRROR : This allows packets to be bounced back to the sender of the packet. For example, if we set up a MIRROR target on destination port HTTP on our INPUT chain and someone tries to access this port, we would bounce his packets back to him and finally he would probably see his own homepage.

 * CONFIG_IP_NF_NAT : This module allows network address translation, or NAT, in its different forms. This option gives us access to the nat table in iptables. This option is required if we want to do port forwarding, masquerading, etc. Note that this option is not required for firewalling and masquerading of a LAN, but you should have it present unless you are able to provide unique IP addresses for all hosts.

 * CONFIG_IP_NF_TARGET_MASQUERADE : This module adds the MASQUERADE target. For instance if we don't know what IP we have to the Internet this would be the preferred way of getting the IP instead of using DNAT or SNAT. In other words, if we use DHCP, PPP, SLIP or some other connection that assigns us an IP, we need to use this target instead of SNAT. Masquerading gives a slightly higher load on the computer than NAT, but will work without us knowing the IP address in advance.

 * CONFIG_IP_NF_TARGET_REDIRECT : This target is useful together with application proxies, for example. Instead of letting a packet pass right through, we remap them to go to our local box instead. In other words, we have the possibility to make a transparent proxy this way.

 * CONFIG_IP_NF_TARGET_LOG : This adds the LOG target and its functionality to iptables. We can use this module to log certain packets to syslogd and hence see what is happening to the packet. This is invaluable for security audits, forensics or debugging a script you are writing.

 * CONFIG_IP_NF_TARGET_TCPMSS : This option can be used to counter Internet Service Providers and servers who block ICMP Fragmentation Needed packets. This can result in web-pages not getting through, small mails getting through while larger mails don't, ssh works but scp dies after handshake, etc. We can then use the TCPMSS target to overcome this by clamping our MSS (Maximum Segment Size) to the PMTU (Path Maximum Transmit Unit). This way, we'll be able to handle what the authors of Netfilter them selves call "criminally brain-dead ISPs or servers" in the kernel configuration help.

 * CONFIG_IP_NF_COMPAT_IPCHAINS : Adds a compatibility mode with the obsolescent ipchains. Do not look to this as any real long term solution for solving migration from Linux 2.2 kernels to 2.4 kernels, since it may well be gone with kernel 2.6.

 * CONFIG_IP_NF_COMPAT_IPFWADM : Compatibility mode with obsolescent ipfwadm. Definitely don't look to this as a real long term solution.

When a packet first enters the firewall, it hits the hardware and then gets passed on to the proper device driver in the kernel. Then the packet starts to go through a series of steps in the kernel, before it is either sent to the correct application (locally), or forwarded to another host - or whatever happens to it.

First, let us have a look at a packet that is destined for our own local host. It would pass through the following steps before actually being delivered to our application that receives it:

Note that this time the packet was passed through the INPUT chain instead of the FORWARD chain. Quite logical. Most probably the only thing that's really logical about the traversing of tables and chains in your eyes in the beginning, but if you continue to think about it, you'll find it will get clearer in time. Now we look at the outgoing packets from our own local host and what steps they go through.

In this example, we're assuming that the packet is destined for another host on another network. The packet goes through the different steps in the following fashion :

As you can see, there are quite a lot of steps to pass through. The packet can be stopped at any of the iptables chains, or anywhere else if it is malformed; however, we are mainly interested in the iptables aspect of this lot. Do note that there are no specific chains or tables for different interfaces or anything like that. FORWARD is always passed by all packets that are forwarded over this firewall/router.

Do not use the INPUT chain to filter on in the previous scenario! INPUT is meant solelyfor packets to our local host that do not get routed to any otherdestination.

We have now seen how the different chains are traversed in three separate scenarios. If we were to figure out a good map of all this, it would look something like this:

To clarify this image, consider this. If we get a packet into the first routing decision that is not destined for the local machine itself, it will be routed through the FORWARD chain. If the packet is, on the other hand, destined for an IP address that the local machine is listening to, we would send the packet through the INPUT chain and to the local machine.

Also worth a note, is the fact that packets may be destined for the local machine, but the destination address may be changed within the PREROUTING chain by doing NAT. Since this takes place before the first routing decision, the packet will be looked upon after this change. Because of this, the routing may be changed before the routing decision is done. Do note, that all packets will be going through one or the other path in this image. If you DNAT a packet back to the same network that it came from, it will still travel through the rest of the chains until it is back out on the network.

Mangle table
This table should as we've already noted mainly be used for mangling packets. In other words, you may freely use the mangle matches etc that could be used to change TOS (Type Of Service) fields and so on.

You are strongly advised not to use this table for any filtering; nor will any DNAT, SNAT or Masquerading work in this table.

Targets that are only valid in the mangle table:
 * TOS
 * TTL
 * MARK

The TOS target is used to set and/or change the Type of Service field in the packet. This could be used for setting up policies on the network regarding how a packet should be routed and so on. Note that this has not been perfected and is not really implemented on the Internet and most of the routers don't care about the value in this field, and sometimes, they act faulty on what they get. Don't set this in other words for packets going to the Internet unless you want to make routing decisions on it, with iproute2.

The TTL target is used to change the TTL (Time To Live) field of the packet. We could tell packets to only have a specific TTL and so on. One good reason for this could be that we don't want to give ourself away to nosy Internet Service Providers. Some Internet Service Providers do not like users running multiple computers on one single connection, and there are some Internet Service Providers known to look for a single host generating different TTL values, and take this as one of many signs of multiple computers connected to a single connection.

The MARK target is used to set special mark values to the packet. These marks could then be recognized by the iproute2 programs to do different routing on the packet depending on what mark they have, or if they don't have any. We could also do bandwidth limiting and Class Based Queuing based on these marks.

NAT table
This table should only be used for NAT (Network Address Translation) on different packets. In other words, it should only be used to translate the packet's source field or destination field. Note that, as we have said before, only the first packet in a stream will hit this chain. After this, the rest of the packets will automatically have the same action taken on them as the first packet. The actual targets that do these kind of things are:
 * DNAT
 * SNAT
 * MASQUERADE

The DNAT target is mainly used in cases where you have a public IP and want to redirect accesses to the firewall to some other host (on a DMZ for example). In other words, we change the destination address of the packet and reroute it to the host.

SNAT is mainly used for changing the source address of packets. For the most part you'll hide your local networks or DMZ, etc. A very good example would be that of a firewall of which we know outside IP address, but need to substitute our local network's IP numbers with that of our firewall. With this target the firewall will automatically SNAT and De-SNAT the packets, hence making it possible to make connections from the LAN to the Internet. If your network uses 192.168.0.0/netmask for example, the packets would never get back from the Internet, because IANA has regulated these networks (among others) as private and only for use in isolated LANs.

The MASQUERADE target is used in exactly the same way as SNAT, but the MASQUERADE target takes a little bit more overhead to compute. The reason for this, is that each time that the MASQUERADE target gets hit by a packet, it automatically checks for the IP address to use, instead of doing as the SNAT target does - just using the single configured IP address. The MASQUERADE target makes it possible to work properly with Dynamic DHCP IP addresses that your ISP might provide for your PPP, PPPoE or SLIP connections to the Internet.

Filter table
The filter table is mainly used for filtering packets. We can match packets and filter them in whatever way we want. This is the place that we actually take action against packets and look at what they contain and DROP or /ACCEPT them, depending on their content. Of course we may also do prior filtering; however, this particular table, is the place for which filtering was designed. Almost all targets are usable in this chain. We will be more prolific about the filter table here; however you now know that this table is the right place to do your main filtering.

The state machine
The state machine is a special part within iptables that should really not be called the state machine at all, since it is really a connection tracking machine. However, most people recognize it under the first name. Throughout this chapter i will use this names more or less as if they were synonymous. This should not be overly confusing. Connection tracking is done to let the Netfilter framework know the state of a specific connection. Firewalls that implement this are generally called stateful firewalls. A stateful firewall is generally much more secure than non-stateful firewalls since it allows us to write much tighter rule-sets.

Within iptables, packets can be related to tracked connections in four different so called states. These are known as NEW, ESTABLISHED, RELATED and INVALID. We will discuss each of these in more depth later. With the --state match we can easily control who or what is allowed to initiate new sessions.

All of the connection tracking is done by special framework within the kernel called conntrack. conntrack may be loaded either as a module, or as an internal part of the kernel itself. Most of the time, we need and want more specific connection tracking than the default conntrack engine can maintain. Because of this, there are also more specific parts of conntrack that handles the TCP, UDP or ICMP protocols among others. These modules grabs specific, unique, information from the packets, so that they may keep track of each stream of data. The information that conntrack gathers is then used to tell conntrack in which state the stream is currently in. For example, UDP streams are, generally, uniquely identified by their destination IP address, source IP address, destination port and source port. In previous kernels, we had the possibility to turn on and off defragmentation. However, since iptables and Netfilter were introduced and connection tracking in particular, this option was gotten rid of. The reason for this is that connection tracking can not work properly without defragmenting packets, and hence defragmenting has been incorporated into conntrack and is carried out automatically. It can not be turned off, except by turning off connection tracking. Defragmentation is always carried out if connection tracking is turned on.

All connection tracking is handled in the PREROUTING chain, except locally generated packets which are handled in the OUTPUT chain. What this means is that iptables will do all recalculation of states and so on within the PREROUTING chain. If we send the initial packet in a stream, the state gets set to NEW within the OUTPUT chain, and when we receive a return packet, the state gets changed in the PREROUTING chain to ESTABLISHED, and so on. If the first packet is not originated by ourself, the NEW state is set within the PREROUTING chain of course. So, all state changes and calculations are done within the PREROUTING and OUTPUT chains of the nat table.

The conntrack entries
Let's take a brief look at a conntrack entry and how to read them in /proc/net/ip_conntrack. This gives a list of all the current entries in your conntrack database. If you have the ip_conntrack module loaded, a cat of /proc/net/ip_conntrack might look like:

tcp     6 117 SYN_SENT src=192.168.1.6 dst=192.168.1.9 sport=32775 \ dport=22 [UNREPLIED] src=192.168.1.9 dst=192.168.1.6 sport=22 \ dport=32775 use=2

This example contains all the information that the conntrack module maintains to know which state a specific connection is in. First of all, we have a protocol, which in this case is tcp. Next, the same value in normal decimal coding. After this, we see how long this conntrack entry has to live. This value is set to 117 seconds right now and is decremented regularly until we see more traffic. This value is then reset to the default value for the specific state that it is in at that relevant point of time. Next comes the actual state that this entry is in at the present point of time. In the above mentioned case we are looking at a packet that is in the SYN_SENT state. The internal value of a connection is slightly different from the ones used externally with iptables. The value SYN_SENT tells us that we are looking at a connection that has only seen a TCP SYN packet in one direction. Next, we see the source IP address, destination IP address, source port and destination port. At this point we see a specific keyword that tells us that we have seen no return traffic for this connection. Lastly, we see what we expect of return packets. The information details the source IP address and destination IP address (which are both inverted, since the packet is to be directed back to us). The same thing goes for the source port and destination port of the connection. These are the values that should be of any interest to us.

The connection tracking entries may take on a series of different values, all specified in the conntrack headers available in linux/include/netfilter-ipv4/ip_conntrack*.h files. These values are dependent on which sub-protocol of IP we use. TCP, UDP or ICMP protocols take specific default values as specified in linux/include/netfilter-ipv4/ip_conntrack.h. We will look closer at this when we look at each of the protocols; however, we will not use them extensively through this chapter, since they are not used outside of the conntrack internals. Also, depending on how this state changes, the default value of the time until the connection is destroyed will also change.

Recently there was a new patch made available in iptables patch-o-matic, called tcp-window-tracking. This patch adds, among other things, all of the above timeouts to special sysctl variables, which means that they can be changed on the fly, while the system is still running. Hence, this makes it unnecessary to recompile the kernel every time you want to change the timeouts. These can be altered via using specific system calls available in the /proc/sys/net/ipv4/netfilter directory. You should in particular look at the /proc/sys/net/ipv4/netfilter/ip_ct_* variables.

When a connection has seen traffic in both directions, the conntrack entry will erase the [UNREPLIED] flag, and then reset it. The entry tells us that the connection has not seen any traffic in both directions, will be replaced by the [ASSURED] flag, to be found close to the end of the entry. The [ASSURED] flag tells us that this connection is assured and that it will not be erased if we reach the maximum possible tracked connections. Thus, connections marked as [ASSURED] will not be erased, contrary to the non assured connections (those not marked as [ASSURED]). How many connections that the connection tracking table can hold depends upon a variable that can be set through the ip-sysctl functions in recent kernels. The default value held by this entry varies heavily depending on how much memory you have. On 128 MB of RAM, you will get 8192 possible entries, and at 256 MB of RAM, you will get 16376 entries. You can read and set your settings through the /proc/sys/net/ipv4/ip_conntrack_max setting.

User-land states
As you have seen, packets may take on several different states within the kernel itself, depending on what protocol we are talking about. However, outside the kernel, we only have the 4 states as described previously. These states can mainly be used in conjunction with the state match which will then be able to match packets based on their current connection tracking state. The valid states are NEW, ESTABLISHED, RELATED and INVALID states. The following table will briefly explain each possible state

These states can be used together with the --state match to match packets based on their connection tracking state. This is what makes the state machine so incredibly strong and efficient for our firewall. Previously, we often had to open up all ports above 1024 to let all traffic back into our local networks again. With the state machine in place this is not necessary any longer, since we can now just open up the firewall for return traffic and not for all kinds of other traffic.

TCP connections
In this section and the upcoming ones, we will take a closer look at the states and how they are handled for each of the three basic protocols TCP, UDP and ICMP. Also, we will take a closer look at how connections are handled per default, if they can not be classified as either of these three protocols. We have chosen to start out with the TCP protocol since it is a stateful protocol in itself, and has a lot of interesting details with regard to the state machine in iptables.

A TCP connection is always initiated with the 3-way handshake, which establishes and negotiates the actual connection over which data will be sent. The whole session is begun with a SYN packet, then a SYN/ACK packet and finally an ACK packet to acknowledge the whole session establishment. At this point the connection is established and able to start sending data. The big problem is, how does connection tracking hook up into this? Quite simply really.

As far as the user is concerned, connection tracking works basically the same for all connection types. Have a look at the picture below to see exactly what state the stream enters during the different stages of the connection. As you can see, the connection tracking code does not really follow the flow of the TCP connection, from the users viewpoint. Once it has seen one packet(the SYN), it considers the connection as NEW. Once it sees the return packet(SYN/ACK), it considers the connection as ESTABLISHED. If you think about this a second, you will understand why. With this particular implementation, you can allow NEW and ESTABLISHED packets to leave your local network, only allow ESTABLISHED connections back, and that will work perfectly. Conversely, if the connection tracking machine were to consider the whole connection establishment as NEW, we would never really be able to stop outside connections to our local network, since we would have to allow NEW packets back in again. To make things more complicated, there is a number of other internal states that are used for TCP connections inside the kernel, but which are not available for us in User-land. Roughly, they follow the state standards specified within RFC 793 - Transmission Control Protocol at page 21-23.

As you can see, it is really quite simple, seen from the user's point of view. However, looking at the whole construction from the kernel's point of view, it's a little more difficult. Let's look at an example. Consider exactly how the connection states change in the /proc/net/ip_conntrack table. The first state is reported upon receipt of the first SYN packet in a connection.

tcp     6 117 SYN_SENT src=192.168.1.5 dst=192.168.1.35 sport=1031 \ dport=23 [UNREPLIED] src=192.168.1.35 dst=192.168.1.5 sport=23 \ dport=1031 use=1

As you can see from the above entry, we have a precise state in which a SYN packet has been sent, (the SYN_SENT flag is set), and to which as yet no reply has been sent (witness the [UNREPLIED] flag). The next internal state will be reached when we see another packet in the other direction.

tcp     6 57 SYN_RECV src=192.168.1.5 dst=192.168.1.35 sport=1031 \ dport=23 src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 \ use=1

Now we have received a corresponding SYN/ACK in return. As soon as this packet has been received, the state changes once again, this time to SYN_RECV. SYN_RECV tells us that the original SYN was delivered correctly and that the SYN/ACK return packet also got through the firewall properly. Moreover, this connection tracking entry has now seen traffic in both directions and is hence considered as having been replied to. This is not explicit, but rather assumed, as was the [UNREPLIED] flag above. The final step will be reached once we have seen the final ACK in the 3-way handshake.

tcp     6 431999 ESTABLISHED src=192.168.1.5 dst=192.168.1.35 \ sport=1031 dport=23 src=192.168.1.35 dst=192.168.1.5 \ sport=23 dport=1031 use=1

In the last example, we have gotten the final ACK in the 3-way handshake and the connection has entered the ESTABLISHED state, as far as the internal mechanisms of iptables are aware. After a few more packets, the connection will also become [ASSURED], as shown in the introduction section of this chapter. When a TCP connection is closed down, it is done in the following way and takes the following states.

As you can see, the connection is never really closed until the last ACK is sent. Do note that this picture only describes how it is closed down under normal circumstances. A connection may also, for example, be closed by sending a RST(reset), if the connection were to be refused. In this case, the connection would be closed down after a predetermined time.

When the TCP connection has been closed down, the connection enters the TIME_WAIT state, which is per default set to 2 minutes. This is used so that all packets that have gotten out of order can still get through our rule-set, even after the connection has already closed. This is used as a kind of buffer time so that packets that have gotten stuck in one or another congested router can still get to the firewall, or to the other end of the connection.

If the connection is reset by a RST packet, the state is changed to CLOSE. This means that the connection per default have 10 seconds before the whole connection is definitely closed down. RST packets are not acknowledged in any sense, and will break the connection directly. There are also other states than the ones we have told you about so far.

Here is the complete list of possible states that a TCP stream may take, and their timeout values.

These values are most definitely not absolute. They may change with kernel revisions, and they may also be changed via the proc file-system in the /proc/sys/net/ipv4/netfilter/ip_ct_tcp_* variables. The default values should, however, be fairly well established in practice. These values are set in jiffies (or 1/100th parts of seconds), so 3000 means 30 seconds.

Also note that the User-land side of the state machine does not look at TCP flags set in the TCP packets. This is generally bad, since you may want to allow packets in the NEW state to get through the firewall, but when you specify the NEW flag, you will in most cases mean SYN packets.

UDP connections
UDP connections are in them selves not stateful connections, but rather stateless. There are several reasons why, mainly because they don't contain any connection establishment or connection closing; most of all they lack sequencing. Receiving two UDP datagrams in a specific order does not say anything about which order in which they were sent. It is, however, still possible to set states on the connections within the kernel. Let's have a look at how a connection can be tracked and how it might look in conntrack.

As you can see, the connection is brought up almost exactly in the same way as a TCP connection. That is, from the user-land point of view. Internally, conntrack information looks quite a bit different, but intrinsically the details are the same. First of all, let's have a look at the entry after the initial UDP packet has been sent.

udp     17 20 src=192.168.1.2 dst=192.168.1.5 sport=137 dport=1025 \ [UNREPLIED] src=192.168.1.5 dst=192.168.1.2 sport=1025 \ dport=137 use=1

As you can see from the first and second values, this is an UDP packet. The first is the protocol name, and the second is protocol number. This is just the same as for TCP connections. The third value marks how many seconds this state entry has to live. After this, we get the values of the packet that we have seen and the future expectations of packets over this connection reaching us from the initiating packet sender. These are the source, destination, source port and destination port. At this point, the [UNREPLIED] flag tells us that there's so far been no response to the packet. Finally, we get a brief list of the expectations for returning packets. Do note that the latter entries are in reverse order to the first values. The timeout at this point is set to 30 seconds, as per default.

udp     17 170 src=192.168.1.2 dst=192.168.1.5 sport=137 \ dport=1025 src=192.168.1.5 dst=192.168.1.2 sport=1025 \ dport=137 use=1

At this point the server has seen a reply to the first packet sent out and the connection is now considered as ESTABLISHED. This is not shown in the connection tracking, as you can see. The main difference is that the [UNREPLIED] flag has now gone. Moreover, the default timeout has changed to 180 seconds - but in this example that's by now been decremented to 170 seconds - in 10 seconds' time, it will be 160 seconds. There's one thing that's missing, though, and can change a bit, and that is the [ASSURED] flag described above. For the [ASSURED] flag to be set on a tracked connection, there must have been a small amount of traffic over that connection.

udp     17 175 src=192.168.1.5 dst=195.22.79.2 sport=1025 \ dport=53 src=195.22.79.2 dst=192.168.1.5 sport=53 \ dport=1025 [ASSURED] use=1

At this point, the connection has become assured. The connection looks exactly the same as the previous example, except for the [ASSURED] flag. If this connection is not used for 180 seconds, it times out. 180 Seconds is a comparatively low value, but should be sufficient for most use. This value is reset to its full value for each packet that matches the same entry and passes through the firewall, just the same as for all of the internal states.

ICMP connections
ICMP packets are far from a stateful stream, since they are only used for controlling and should never establish any connections. There are four ICMP types that will generate return packets however, and these have 2 different states. These ICMP messages can take the NEW and ESTABLISHED states. The ICMP types we are talking about are Echo request and reply, Timestamp request and reply, Information request and reply and finally Address mask request and reply. Out of these, the timestamp request and information request are obsolete and could most probably just be dropped. However, the Echo messages are used in several setups such as pinging hosts. Address mask requests are not used often, but could be useful at times and worth allowing. To get an idea of how this could look, have a look at the following image.

As you can see in the above picture, the host sends an echo request to the target, which is considered as NEW by the firewall. The target then responds with a echo reply which the firewall considers as state ESTABLISHED. When the first echo request has been seen, the following state entry goes into the ip_conntrack.

icmp    1 25 src=192.168.1.6 dst=192.168.1.10 type=8 code=0 \ id=33029 [UNREPLIED] src=192.168.1.10 dst=192.168.1.6 \ type=0 code=0 id=33029 use=1

This entry looks a little bit different from the standard states for TCP and UDP as you can see. The protocol is there, and the timeout, as well as source and destination addresses. The problem comes after that however. We now have 3 new fields called type, code and id. They are not special in any way, the type field contains the ICMP type and the code field contains the ICMP code. These are all available in ICMP types appendix. The final id field, contains the ICMP ID. Each ICMP packet gets an ID set to it when it is sent, and when the receiver gets the ICMP message, it sets the same ID within the new ICMP message so that the sender will recognize the reply and will be able to connect it with the correct ICMP request.

The next field, we once again recognize as the [UNREPLIED] flag, which we have seen before. Just as before, this flag tells us that we are currently looking at a connection tracking entry that has seen only traffic in one direction. Finally, we see the reply expectation for the reply ICMP packet, which is the inversion of the original source and destination IP addresses. As for the type and code, these are changed to the correct values for the return packet, so an echo request is changed to echo reply and so on. The ICMP ID is preserved from the request packet.

The reply packet is considered as being ESTABLISHED, as we have already explained. However, we can know for sure that after the ICMP reply, there will be absolutely no more legal traffic in the same connection. For this reason, the connection tracking entry is destroyed once the reply has traveled all the way through the Netfilter structure.

In each of the above cases, the request is considered as NEW, while the reply is considered as ESTABLISHED. Let's consider this more closely. When the firewall sees a request packet, it considers it as NEW. When the host sends a reply packet to the request it is considered ESTABLISHED.

Note that this means that the reply packet must match the criterion given by the connection tracking entry to be considered as established, just as with all other traffic types.

ICMP requests has a default timeout of 30 seconds, which you can change in the /proc/sys/net/ipv4/netfilter/ip_ct_icmp_timeout entry. This should in general be a good timeout value, since it will be able to catch most packets in transit.

Another hugely important part of ICMP is the fact that it is used to tell the hosts what happened to specific UDP and TCP connections or connection attempts. For this simple reason, ICMP replies will very often be recognized as RELATED to original connections or connection attempts. A simple example would be the ICMP Host unreachable or ICMP Network unreachable. These should always be spawned back to our host if it attempts an unsuccessful connection to some other host, but the network or host in question could be down, and hence the last router trying to reach the site in question will reply with an ICMP message telling us about it. In this case, the ICMP reply is considered as a RELATED packet. The following picture should explain how it would look.

In the above example, we send out a SYN packet to a specific address. This is considered as a NEW connection by the firewall. However, the network the packet is trying to reach is unreachable, so a router returns a network unreachable ICMP error to us. The connection tracking code can recognize this packet as RELATED. thanks to the already added tracking entry, so the ICMP reply is correctly sent to the client which will then hopefully abort. Meanwhile, the firewall has destroyed the connection tracking entry since it knows this was an error message.

The same behavior as above is experienced with UDP connections if they run into any problem like the above. All ICMP messages sent in reply to UDP connections are considered as RELATED. Consider the following image.

This time an UDP packet is sent to the host. This UDP connection is considered as NEW. However, the network is administratively prohibited by some firewall or router on the way over. Hence, our firewall receives a ICMP Network Prohibited in return. The firewall knows that this ICMP error message is related to the already opened UDP connection and sends it as an RELATED packet to the client. At this point, the firewall destroys the connection tracking entry, and the client receives the ICMP message and should hopefully abort.

Default connections
In certain cases, the conntrack machine does not know how to handle a specific protocol. This happens if it does not know about that protocol in particular, or doesn't know how it works. In these cases, it goes back to a default behavior. The default behavior is used on, for example, NETBLT, MUX and EGP. This behavior looks pretty much the same as the UDP connection tracking. The first packet is considered NEW, and reply traffic and so forth is considered ESTABLISHED.

When the default behavior is used, all of these packets will attain the same default timeout value. This can be set via the /proc/sys/net/ipv4/netfilter/ip_ct_generic_timeout variable. The default value here is 600 seconds, or 10 minutes. Depending on what traffic you are trying to send over a link that uses the default connection tracking behavior, this might need changing. Especially if you are bouncing traffic through satellites and such, which can take a long time.

Complex protocols and connection tracking
Certain protocols are more complex than others. What this means when it comes to connection tracking, is that such protocols may be harder to track correctly. Good examples of these are the ICQ, IRC and FTP protocols. Each and every one of these protocols carries information within the actual data payload of the packets, and hence requires special connection tracking helpers to enable it to function correctly.

Let's take the FTP protocol as the first example. The FTP protocol first opens up a single connection that is called the FTP control session. When we issue commands through this session, other ports are opened to carry the rest of the data related to that specific command. These connections can be done in two ways, either actively or passively. When a connection is done actively, the FTP client sends the server a port and IP address to connect to. After this, the FTP client opens up the port and the server connects to that specified port from its own port 20 (known as FTP-Data) and sends the data over it.

The problem here is that the firewall will not know about these extra connections, since they were negotiated within the actual payload of the protocol data. Because of this, the firewall will be unable to know that it should let the server connect to the client over these specific ports.

The solution to this problem is to add a special helper to the connection tracking module which will scan through the data in the control connection for specific syntaxes and information. When it runs into the correct information, it will add that specific information as RELATED and the server will be able to track the connection, thanks to that RELATED entry. Consider the following picture to understand the states when the FTP server has made the connection back to the client.

Passive FTP works the opposite way. The FTP client tells the server that it wants some specific data, upon which the server replies with an IP address to connect to and at what port. The client will, upon receipt of this data, connect to that specific port, from its own port 20(the FTP-data port), and get the data in question. If you have an FTP server behind your firewall, you will in other words require this module in addition to your standard iptables modules to let clients on the Internet connect to the FTP server properly. The same goes if you are extremely restrictive to your users, and only want to let them reach HTTP and FTP servers on the Internet and block all other ports. Consider the following image and its bearing on Passive FTP.

Some conntrack helpers are already available within the kernel itself. More specifically, the FTP and IRC protocols have conntrack helpers as of writing this. If you can not find the conntrack helpers that you need within the kernel itself, you should have a look at the patch-o-matic tree within user-land iptables. The patch-o-matic tree may contain more conntrack helpers, such as for the ntalk or H.323 protocols.

Conntrack helpers may either be statically compiled into the kernel, or as modules. If they are compiled as modules, you can load them with the following command :

modprobe ip_conntrack_*

Do note that connection tracking has nothing to do with NAT, and hence you may require more modules if you are NAT'ing connections as well. For example, if you were to want to NAT and track FTP connections, you would need the NAT module as well. All NAT helpers starts with ip_nat_ and follow that naming convention; so for example the FTP NAT helper would be named ip_nat_ftp and the IRC module would be named ip_nat_irc. The conntrack helpers follow the same naming convention, and hence the IRC conntrack helper would be named ip_conntrack_irc, while the FTP conntrack helper would be named ip_conntrack_ftp.

How a rule is built
As we have already explained, each rule is a line that the kernel looks at to find out what to do with a packet. If all the criteria - or matches - are met, we perform the target - or jump - instruction. Normally we would write our rules in a syntax that looks something like this:

iptables [-t table] command [match] [target/jump]

There is nothing that says that the target instruction has to be last function in the line. However, you would usually adhere to this syntax to get the best readability. Anyway, most of the rules you'll see are written in this way. Hence, if you read someone else's script, you'll most likely recognize the syntax and easily understand the rule.

If you want to use another table than the standard table, you could insert the table specification at the point at which [table] is specified. However, it is not necessary to state explicitly what table to use, since by default iptables uses the filter table on which to implement all commands. Neither do you have to specify the table at just this point in the rule. It could be set pretty much anywhere along the line. However, it is more or less standard to put the table specification at the beginning.

One thing to think about though: The command should always come first, or alternatively directly after the table specification. We use 'command' to tell the program what to do, for example to insert a rule or to add a rule to the end of the chain, or to delete a rule. We shall take a further look at this below. The match is the part of the rule that we send to the kernel that details the specific character of the packet, what makes it different from all other packets. Here we could specify what IP address the packet comes from, from which network interface, the intended IP address, port, protocol or whatever. There is a heap of different matches that we can use that we will look closer at further down.

Finally we have the target of the packet. If all the matches are met for a packet, we tell the kernel what to do with it. We could, for example, tell the kernel to send the packet to another chain that we've created ourselves, and which is part of this particular table. We could tell the kernel to drop the packet dead and do no further processing, or we could tell the kernel to send a specified reply to the sender. As with the rest of the content in this section, we'll look closer at it further down.

Tables
The -t option specifies which table to use. Per default, the filter table is used. We may specify one of the following tables with the -t option. Do note that this is an extremely brief summary

Commands
In this section we will cover all the different commands and what can be done with them. The command tells iptables what to do with the rest of the rule that we send to the parser. Normally we would want either to add or delete something in some table or another. The following commands are available to iptables:

You should always enter a complete command line, unless you just want to list the built-in help for iptables or get the version of the command. To get the version, use the -v option and to get the help message, use the -h option. As usual, in other words. Next comes a few options that can be used with various different commands. Note that we tell you with which commands the options can be used and what effect they will have. Also note that we do not include any options here that affect rules or matches. Instead, we'll take a look at matches and targets in a later section of this chapter.

Options :

Matches
First of all we have the generic matches, which can be used in all rules. Then we have the TCP matches which can only be applied to TCP packets. We have UDP matches which can only be applied to UDP packets, and ICMP matches which can only be used on ICMP packets. Finally we have special matches, such as the state, owner and limit matches and so on. These final matches have in turn been narrowed down to even more subcategories, even though they might not necessarily be different matches at all.

Generic matches
This section will deal with Generic matches. A generic match is a kind of match that is always available, whatever kind of protocol we are working on, or whatever match extensions we have loaded. No special parameters at all are needed to use these matches; in other words. I have also included the --protocol match here, even though it is more specific to protocol matches. For example, if we want to use a TCP match, we need to use the --protocol match and send TCP as an option to the match. However, --protocol is also a match in itself, since it can be used to match specific protocols. The following matches are always available.

Generic matches

Implicit matches
Those are matches that are loaded implicitly. Implicit matches are implied, taken for granted, automatic. For example when we match on --protocol tcp without any further criteria. There are currently three types of implicit matches for three different protocols. These are TCP matches, UDP matches and ICMP matches. The TCP based matches contain a set of unique criteria that are available only for TCP packets. UDP based matches contain another set of criteria that are available only for UDP packets. And the same thing for ICMP packets. On the other hand, there can be explicit matches that are loaded explicitly. Explicit matches are not implied or automatic, you have to specify them specifically. For these you use the -m or --match option, which we will discuss in the next section.

TCP matches
These matches are protocol specific and are only available when working with TCP packets and streams. To use these matches, you need to specify --protocol tcp on the command line before trying to use them. Note that the --protocol tcp match must be to the left of the protocol specific matches. These matches are loaded implicitly in a sense, just as the UDP and ICMP matches are loaded implicitly. The other matches will be looked over in the continuation of this section, after the TCP match section.

UDP matches
will only work together with UDP packets. These matches are implicitly loaded when you specify the --protocol UDP match and will be available after this specification. Note that UDP packets are not connection oriented, and hence there is no such thing as different flags to set in the packet to give data on what the datagram is supposed to do, such as open or closing a connection, or if they are just simply supposed to send data. UDP packets do not require any kind of acknowledgment either. If they are lost, they are simply lost (Not taking ICMP error messaging etc into account). This means that there are quite a lot less matches to work with on a UDP packet than there is on TCP packets. Note that the state machine will work on all kinds of packets even though UDP or ICMP packets are counted as connectionless protocols. The state machine works pretty much the same on UDP packets as on TCP packets.

ICMP matches
These are the ICMP matches. These packets are even more ephemeral, that is to say short lived, than UDP packets, in the sense that they are connectionless. The ICMP protocol is mainly used for error reporting and for connection controlling and suchlike. ICMP is not a protocol subordinated to the IP protocol, but more of a protocol that augments the IP protocol and helps in handling errors. The headers of ICMP packets are very similar to those of the IP headers, but differ in a number of ways. The main feature of this protocol is the type header, that tells us what the packet is for. One example is, if we try to access an unaccessible IP address, we would normally get an ICMP host unreachable in return. For a complete listing of ICMP types, see the ICMP types appendix. There is only one ICMP specific match available for ICMP packets, and hopefully this should suffice. This match is implicitly loaded when we use the --protocol ICMP match and we get access to it automatically. Note that all the generic matches can also be used, so that among other things we can match on the source and destination addresses.

Explicit matches
Explicit matches are those that have to be specifically loaded with the -m or --match option. State matches, for example, demand the directive -m state prior to entering the actual match that you want to use. Some of these matches may be protocol specific. Some may be unconnected with any specific protocol - for example connection states. These might be NEW (the first packet of an as yet unestablished connection), ESTABLISHED (a connection that is already registered in the kernel), RELATED (a new connection that was created by an older, established one) etc. A few may just have been evolved for testing or experimental purposes, or just to illustrate what iptables is capable of. This in turn means that not all of these matches may at first sight be of any use. Nevertheless, it may well be that you personally will find a use for specific explicit matches. And there are new ones coming along all the time, with each new iptables release. Whether you find a use for them or not depends on your imagination and your needs. The difference between implicitly loaded matches and explicitly loaded ones, is that the implicitly loaded matches will automatically be loaded when, for example, you match on the properties of TCP packets, while explicitly loaded matches will never be loaded automatically - it is up to you to discover and activate explicit matches.

Limit match
The limit match extension must be loaded explicitly with the -m limit option. This match can, for example, be used to advantage to give limited logging of specific rules etc. For example, you could use this to match all packets that does not exceed a given value, and after this value has been exceeded, limit logging of the event in question. Think of a time limit : You could limit how many times a certain rule may be matched in a certain time frame, for example to lessen the effects of DoS syn flood attacks. This is its main usage, but there are more usages, of course. The limit match may also be inverted by adding a ! flag in front of the limit match. It would then be expressed as -m limit ! --limit 5/s.This means that all packets will be matched after they have broken thelimit.

To further explain the limit match, it is basically a token bucket filter. Consider having a leaky bucket where the bucket leaks X packets per time-unit. X is defined depending on how many matching packets we get, so if we get 3 packets, the bucket leaks 3 packets per that time-unit. The --limit option tells us how many packets to refill the bucket with per time-unit, while the --limit-burst option tells us how big the bucket is in the first place. So, setting --limit 3/minute --limit-burst 5, and then receiving 5 matches will empty the bucket. After 20 seconds, the bucket is refilled with another token, and so on until the --limit-burst is reached again or until they get used.

Consider the example below for further explanation of how this may look.
 * 1) We set a rule with -m limit --limit 5/second --limit-burst 10. The limit-burst token bucket is set to 10 initially. Each packet that matches the rule uses a token.
 * 2) We get packet that matches, 1-2-3-4-5-6-7-8-9-10, all within a 1/1000 of a second.
 * 3) The token bucket is now empty. Once the token bucket is empty, the packets that qualify for the rule otherwise no longer match the rule and proceed to the next rule if any, or hit the chain policy.
 * 4) For each 1/5 s without a matching packet, the token count goes up by 1, upto a maximum of 10. 2 seconds after receiving the 10 packets, we will once again have 10 tokens left.
 * 5) And of course, the bucket will be emptied by 1 token for each packet it receives.

MAC match
The MAC (Ethernet Media Access Control) match can be used to match packets based on their MAC source address. As of writing this documentation, this match is a little bit limited, however, in the future this may be more evolved and may be more useful. This match can be used to match packets on the source MAC address only as previously said.

Do note that to use this module we explicitly load it with the -m mac option. The reason that I am saying this is that a lot of people wonder if it should not be -m mac-source, which it should not.

Mark match
The mark match extension is used to match packets based on the marks they have set. A mark is a special field, only maintained within the kernel, that is associated with the packets as they travel through the computer. Marks may be used by different kernel routines for such tasks as traffic shaping and filtering. As of today, there is only one way of setting a mark in Linux, namely the MARK target in iptables. This was previously done with the FWMARK target in ipchains, and this is why people still refer to FWMARK in advanced routing areas. The mark field is currently set to an unsigned integer, or 4294967296 possible values on a 32 bit system. In other words, you are probably not going to run into this limit for quite some time.

Multiport match
The multiport match extension can be used to specify multiple destination ports and port ranges. Without the possibility this match gives, you would have to use multiple rules of the same type, just to match different ports.

You can not use both standard port matching and multiport matching at the same time, for example you can't write: --sport 1024:63353 -m multiport --dport 21,23,80. This will simply not work. What in fact happens, if you do, is that iptables honors the first element in the rule, and ignores the multiport instruction.

Owner match
The owner match extension is used to match packets based on the identity of the process that created them. The owner can be specified as the process ID either of the user who issued the command in question, that of the group, the process, the session, or that of the command itself. This extension was originally written as an example of what iptables could be used for. The owner match only works within the OUTPUT chain, for obvious reasons: It is pretty much impossible to find out any information about the identity of the instance that sent a packet from the other end, or where there is an intermediate hop to the real destination. Even within the OUTPUT chain it is not very reliable, since certain packets may not have an owner. Notorious packets of that sort are (among other things) the different ICMP responses. ICMP responses will never match.

State match
The state match extension is used in conjunction with the connection tracking code in the kernel. The state match accesses the connection tracking state of the packets from the conntracking machine. This allows us to know in what state the connection is, and works for pretty much all protocols, including stateless protocols such as ICMP and UDP. In all cases, there will be a default timeout for the connection and it will then be dropped from the connection tracking database. This match needs to be loaded explicitly by adding a -m state statement to the rule. You will then have access to one new match called state.

TOS match
The TOS match can be used to match packets based on their TOS field. TOS stands for Type Of Service, consists of 8 bits, and is located in the IP header. This match is loaded explicitly by adding -m tos to the rule. TOS is normally used to inform intermediate hosts of the precedence of the stream and its content (it doesn't really, but it informs of any specific requirements for the stream, such as it having to be sent as fast as possible, or it needing to be able to send as much payload as possible). How different routers and administrators deal with these values depends. Most do not care at all, while others try their best to do something good with the packets in question and the data they provide.

TTL match
The TTL match is used to match packets based on their TTL (Time To Live) field residing in the IP headers. The TTL field contains 8 bits of data and is decremented once every time it is processed by an intermediate host between the client and recipient host. If the TTL reaches 0, an ICMP type 11 code 0 (TTL equals 0 during transit) or code 1 (TTL equals 0 during reassembly) is transmitted to the party sending the packet and informing it of the problem. This match is only used to match packets based on their TTL, and not to change anything. The latter, incidentally, applies to all kinds of matches. To load this match, you need to add an -m ttl to the rule.

Targets/Jumps
The target/jumps tells the rule what to do with a packet that is a perfect match with the match section of the rule. There are a couple of basic targets, the ACCEPT and DROP targets, which we will deal with first. However, before we do that, let us have a brief look at how a jump is done.

The jump specification is done in exactly the same way as in the target definition, except that it requires a chain within the same table to jump to. To jump to a specific chain, it is of course a prerequisite that that chain exists. As we have already explained, a user-defined chain is created with the -N command. For example, let's say we create a chain in the filter table called tcp_packets, like this: iptables -N tcp_packets

We could then add a jump target to it like this:

iptables -A INPUT -p tcp -j tcp_packets

We would then jump from the INPUT chain to the tcp_packets chain and start traversing that chain. When/If we reach the end of that chain, we get dropped back to the INPUT chain and the packet starts traversing from the rule one step below where it jumped to the other chain (tcp_packets in this case). If a packet is ACCEPTed within one of the sub chains, it will be ACCEPT'ed in the superset chain also and it will not traverse any of the superset chains any further. However, do note that the packet will traverse all other chains in the other tables in a normal fashion.

Targets on the other hand specify an action to take on the packet in question. We could for example, DROP or ACCEPT the packet depending on what we want to do. There are also a number of other actions we may want to take, which we will describe further on in this section. Jumping to targets may incur different results, as it were. Some targets will cause the packet to stop traversing that specific chain and superior chains as described above. Good examples of such rules are DROP and ACCEPT. Rules that are stopped, will not pass through any of the rules further on in the chain or in superior chains. Other targets, may take an action on the packet, after which the packet will continue passing through the rest of the rules. A good example of this would be the LOG, ULOG and TOS targets. These targets can log the packets, mangle them and then pass them on to the other rules in the same set of chains. We might, for example,


text: Template:LPI Linux Certification/LPIC202

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Wikijunior:Solar System/Oort Cloud

The Oort cloud is a huge halo made of millions of comets that lies at the outermost edge of the Solar System.

What is the Oort Cloud?
Scientists say there is a distant group of objects, made of rock and ice, that forms a cloud-like region surrounding our Solar System. It is a cloud of comet-like objects orbiting far away from the Sun. Even though the comets are very widely scattered from each other, there many millions of them. The total mass of all these comets may be up to 100 times the mass of the Earth. The Oort Cloud is named after a Dutch astronomer Jan Oort who took the original idea, improved upon it and made it widely known.

As a comet makes several passes through the solar system, the Sun slowly melts and vaporizes the ice and only little bits of solid debris are left behind. But if the comets are all destroyed when they pass through the system, then new comets will need to appear. Otherwise we would not see any more comets. Jan Oort used the idea of the Oort cloud to explain why new comets keep appearing.

Where is the Oort Cloud?
If you can imagine the distance from the Earth to the Sun, then the comets in the Oort cloud are 50,000 to 100,000 times further away! That is 1,000 times further away from the Sun than is Pluto, and about one fourth the distance to the nearest neighboring star—Proxima Centauri. Light takes a year to travel from the Sun to the outer edge of the Oort Cloud.

How did the Oort Cloud start?
The Oort cloud objects may have started closer to the Sun during the Solar System's formation. When they passed near the gas giants, the gravity of those planets hurled the objects into very distant orbits. The Oort cloud objects were sent in all directions, making the Oort cloud ball-shaped instead of disk-shaped. The gravity of passing stars also made the orbits of these objects more circular, and pulled them further from the Sun. But sometimes the gravity of other far away stars can send the objects hurtling back toward the Sun. These become the comets.

What objects are in the Oort Cloud?
An object named Sedna has been discovered that may belong to the Oort Cloud (although it is actually between the Kuiper Belt and the Oort Cloud.) It is from 1,180 to 1,800 km across. Its orbit stretches from 76 to 928 times further from the Sun than does the Earth's. Sedna orbits the Sun about once every 11,250 Earth years. The last time Sedna was where it is now in its orbit, Earth's last Ice Age was ending! Some scientists think that Sedna should be included in the Kuiper Belt, making the belt bigger.

Next Page: Glossary

Wikijunior Sonnensystem/ Oortsche Wolke

title: Wikijunior:Solar System/Oort Cloud


text:
Wikijunior talk:Solar System/Oort Cloud

 * Oort_cloud
 * 90377_Sedna

---

Not to knock the work done here but is the oort cloud really appropriate for what is after all a basic intro to the sloar system. I've never heard of it before, and since there seems to be some debate if it is part of the keppler belt or not, maybe it should be cut... The bellman 04:51, 8 Jun 2005 (UTC)

Minor clarification
Current Text: "It is believed that most comets originally were in the Oort Cloud before "falling" into the Sun."

I think falling "into" the Sun might not be what we're looking for - would falling "toward" the Sun be better? Falling into the Sun implies a fiery end for the comet.
 * While I think that the toward is perhaps more correct, "falling into" the sun does indeed happen. In fact, SOHO has seen several with a very fiery end as they go right into the photosphere (with a strong assumption that they don't make it back out).  Perhaps some clarification on the comet page of both types?  I was just trying to put some content in for this page, so don't worry about bruising my ego to make it more correct.Rob Horning 06:32, 24 Jun 2005 (UTC)

Is this really necessary?
The Wikipedia article admits that "The Oort cloud ... is a postulated spherical cloud of comets..." and "Although no direct observations have been made of such a cloud, it is believed to be the source of most or all comets entering the inner solar system...". Is there any evidence that the Oort cloud even exists (besides the fact that comets enter the inner solar system)? And if there isn't, or if the only evidence is one comet that isn't even close to far enough away, why teach this to kids? And why call this armchair speculation science? - SamE 14:32, 7 August 2005 (UTC)
 * There is large amount of evidence to support the Oort cloud, Hubble Space Telescope has seen large amounts of very small (20 km or so) objects in the far outer solar system. N1person 21:26, 19 December 2005 (UTC)

No there is no evidence for the oort cloud, it has never been observed, but guess what, WITHOUT the oort cloud evolution is impossible, they will make it there i am sure. I am sure the vatican would stand up to any silly arguments put forward by nasa about a oort cloud, even a quote from the author, i now doubt the oort cloud exists as there is not a shred of evidence for its existance. Stop teaching junk to kids and brain washing them with propogander nonsence.

90377 Sedna is plenty far enough away. (What about 50000 Quaoar ?). Apparently other smaller objects are not newsworthy enough to make my newspaper. Do you have a reference for any observations of these small objects? The Kuiper Belt and The Oort Cloud seems to imply that Hubble has only seen 1 such object. Have there been more discoveries (by Hubble or anything else) since that was written? There are quite a few obstinate, stubborn people who prefer links and literature references over "the evidence exists, trust me!" :-). --DavidCary 21:10, 16 January 2006 (UTC)

 * I think the problem here is that any observation of objects as small as a typical comet is not likely to occur until after the object becomes a comet and enters the inner Solar System. The objective scientific evidence is comparing the frequence of comets over the past several centuries, especially records of comets by Chinese astronomers over the past three millenia, and extrapolating the number of objects that would hypothetically be needed in the Oort cloud to produce that many comets with the seemingly consistant frequency of these cometary appearances.  Cometary infalls measured by SOHO have given another much larger set of datapoints for smaller objects that are not normally seen by terrestrial telescopes simply because they are so tiny that normally they wouldn't even be seen even if passing between the Earth and the Moon.  As for other Kuiper Belt objects, there have been many, but keep in mind that objects like Sedna and Quaoar have to be large enough to be resolved with current telescopes simply because they emit so little light by reflection that there is hardly anything at all that can be measured at all.  Pluto was right at the resolution limits of telescopes at the time of Tombaugh, and had it been any smaller Pluto would not have been discovered at all.
 * If you want to see a current list of confirmed asteroids, please look at the Minor Planet Center for current updates. This site is the "official" organization that desinates any asteroid discoveries and is the central clearing house for any current asteroid observations, including Kuiper objects.  Of particular interest may be the plot of Kuiper Belt objects which show a large number beyond Neptune.  --Rob Horning 01:51, 17 January 2006 (UTC)

Passing stars?
Reading about passing stars makes me very curious about which ones just passed our solar system given the relative stable positions of the stars in space? My suggestion is that someone will come up with a better explanation or point out these passing stars please. —Preceding unsigned comment added by IArnold (discuss • contribs) 09:09, 1 March 2011

title: Wikijunior talk:Solar System/Oort Cloud


text:
LPI Linux Certification/LPIC2 Exam 202/Exercises results

Troubleshooting network issues
Solution des exercices (LPIC202)


text:
User:Benschop~enwikibooks

Nico F. Benschop

Geldrop (Noord Brabant) - The Netherlands

Researcher at Philips Research Labs (Eindhoven) 1970 - 2002 Prof at TU-Delft/EE (part-time) Digital VLSI Design 1981 - 1987 . . . Retired nov-2002.

Subjects - Digital IC design methods : . . . State-Machines, Arithmetic, Logic circuits . . . Book : The Associative Structure of State Machines, see : . . . . . . http://home.claranet.nl/users/benschop/preface.htm --- (11 chapters, 217 pgs; For sale at http://home.claranet.nl/users/benschop )

Education : HBS-B. . highschool (Ede, Enschede) 1952 - 1957 HTS-EE. . . . . (Enschede - denHaag) 1957 - 1960 Mil.Serv. AirForce. (Breda - Ypenburg) 1960 -1962 TU-Delft. . . . . . . . . . . . . MSc/EE 1966 Univ-Waterloo, Canada. . PhD/EE 1971

Homepage:. . . http://home.claranet.nl/users/benschop Hobbies, see http://home.claranat.nl/users/benschop/play.htm Favorite links http://home.claranet.nl/users/benschop/links.htm

Retrieved from "http://en.wikipedia.org/wiki/User:Benschop" :

Abstract
The Associative Structure of State Machines by Nico F.Benschop.

Subtitle: An Associative Algebra Approach to Logic, Arithmetic and Automata.

New book (Feb.2011: 11 chapters, bibliography, 217 pgs): Engineering synthesis of State-Machines, Arithmetic and Logic. Formal approach (Semigroup structure) - Background: Industrial Research.

Relevant subjects are Associative algebra, Algebraic structure and:

Purpose : This book is intended for researchers at industrial laboratories, teachers and students at technical universities, in electrical engineering, computer science and applied mathematics departments, interested in new developments of modelling and designing digital networks (DN : combinational and sequential logic, arithmetic) in general, as a combined math/engineering discipline. As background an undergraduate level of modern applied algebra will suffice.. [1]. Birkhoff-Bartee (1970) - Modern Applied Algebra [2]. Clifford-Preston (1960) - Algebraic Theory of Semigroups (part I) [3]. Hartmanis-Stearns (1970) - Algebraic structure of Sequential Machines
 * Computer Science: Basic structure of algorithms, software, hardware, Automaton, finite state machine (FSM) : Sequential logic.
 * Finite transformation semigroup: Function Composition, Residue Arithmetic, Electronics/Boolean Algebra : Combinational logic.
 * Electrical Engineering: Digital circuit design, Combinational and Sequential logic, Finite Log-arithmetic with single- and dual bases.

Summary : The basic ideas of algebra relating to the structure of sequential and combinational logic, although well known from discrete mathematics [1][2], will be recalled briefly and, for practical state machine design purposes, interpreted in terms of the original additive and multiplicative arithmetic principles from which they developed in the nineteenth century (essentially the 1840's - Boole, Hamilton, Grassmann) The subsequent three parts follow the developments in reverse historical order: I. Sequential logic (state machines), II. Combinational logic (Boolean algebra), and III. Arithmetic. The respective disciplines: CS/EE/NT (computer science/ electrical engineering digital circuit design/ number theory) are merged under one heading: - - Finite Associative Algebra = Finite transformation Semigroups - - including: -- Non-commutative function composition, for sequential logic -- Commutative arithmetic (+, x) for residues and integers -- Commutative and Idempotent for combinational logic (binary, Boolean)

Structured Design : The original motivation for this work appears in appendix A, which is a report on the state of the art of computing science in 1973 (ICS73 Davos) regarding a controversy about the existence of a software crisis, and the need for more attention to ’structure’ in programming and design. In matters of abstract mathematical material with practical applications, there is the usual dilemma of how to present it: — either top down : starting with an abstract concise definition of the essential concepts involved and developing the consequences, ending up with corollaries, as selected examples of important special cases; — or bottom up : by appealing to practical (engineering) intuition and experience, to begin with special essential examples and applications, and gradually extracting their abstract essence to develop the general theory. This dilemma is here resolved by alternating these two approaches, with a preference for starting bottom-up. By familiar examples in arithmetic, digital circuits or state machines, the essence of a formal viewpoint is introduced, as basis for computer aided design (CAD) synthesis algorithms in practice. Synthesis is taken to mean: efficient binary coding of a - functionally specified - symbolic description of desired sequential or combinational logic behaviour.

Intro : Essential concepts and their engineering interpretation are introduced in a practical fashion with examples, e.g:

- - the elementary components of sequential behaviour (the 5 basic state machine types)
 * The known 5 non-isomorphic semigroups of order 2 as :
 * Any finite semigroup S is the sequential closure of a state Machine, uniquely decomposable as a coupled network of the 5 basic machine types.
 * Two of the five basic component types are non-commutative (branch- and reset- machines), the other three occur in residue arithmetic semigroups.
 * Excluding these non-comm've components, non-commutativity of S can be modelled by coupling - with combinational logic functions - between components (which does not occur if S is commutative).
 * Finite Group Decomposition (of any permutation machine) requires only right-congruence(s), thus proper subgroups suffice. Hence also a non-trivial simple group (like A5, without normal subgroup, resp. full congruence) can be decomposed as a coupled network of prime cycle machines, contrary to Krohn-Rhodes' decomposition which uses only 2 of the 5 basic machine types (reset- and permutation machines) and has the rather complex non-trivial simple groups (minimal order 60) as indecomposable components.
 * Binary Residue Arithmetic : each k-bit odd residue is a unique signed power of 3. So each residue n == +/- 3^i.2^j mod 2^k for unique natural pair i<2^(k-2), j<k, yielding an efficient dual base for log-arithmetic (US patent #5923888).
 * Fault Tolerant Logic by Error Correcting Codes : the known Hamming-code and Product-code methods for reliable transmissions can also be applied to (non-linear) Boolean combinational logic circuits. Practical examples show the trade-off between protection performance and cost.
 * Planar Boolean Functions : a new representation of BFn (n-input Boolean functions) uses the concept of (rank-) spectrum as an ordered sequence of n+1 natural numbers that characterizes a circuit, based on counting paths (minterms) in an orthogonal XY grid onto which a BFn is mapped. An essential algebraic composition property holds : the Spectrum of a (disjoint) product of BF's is the product of their Spectra : Sp(F1 * F2) = Sp(F1) x Sp(F2), where disjoint means: no common input(s).
 * Residue Arithmetic (mod m_k): The additive structure of multiplicative residue arithmetic semigroup S(*) [mod m_k] is analysed, for two characteristic moduli: m_k = p^k (prime power), and m_k = \prod{p_k} (the product of the first k primes). This yields insight into notoriously difficult representation theorems of Fermat, Waring and Goldbach (for integers, by controlled extension of residues with a carry, constructively breaking the Hensel lift ).

-- Preface + table of contents (11 chapters, 217 pgs) -- http://home.claranet.nl/users/benschop/preface.pdf

title: User:Benschop~enwikibooks


text:
User talk:Krischik

Ada
Hi Krischik.

I'm following your book on Ada programming, good work. I just wanted to warn you about a little recurrent spelling error: standart -> standard.

Good luck. ManuelGR 20:29, 15 Nov 2004 (UTC)

Thanks, I watch it - it's a common mistake for native german speakers.

AVR
Thanks for the correction :-)

About category Ada 2005
Please, read Template talk:Ada2005. ManuelGR 19:51, 28 Jan 2005 (UTC)

Computer programming/Types
got additions by AlMac effectively doubling the size of the article since you last worked on it. I just thought you might like to see what I did to it. AlMac 23:50, 17 July 2005 (UTC)

Ada Quality and Style Guide
Hello, I would like to know your opinion about a new proposal I've made about the name of the Ada Quality and Style Guide section. Thanks!

C++ book forkings
Hi Krischik. I've noticed that you're involved with some the C++ book discussions. As you may know, I have called for administrators to look at the issue, at Panic2k4's request, of the forced a merge of the forked content with what is now two C++ books. If you could add your eyeballs to this it would be greatly appreciated by all. MShonle 04:43, 9 September 2005 (UTC)

Naming of language books
Hi Krischik. Panic2k4 has recently been renaming the "C -/- -/-" book and left a note saying it was by your suggestion?

 * Programming:C -/- -/- was thinking aobut a new name and I was pointing out the [WB:NP]]

The name has been changed to "Programming in C -/- -/-" (not that it much matters, since it will be deleted in less than two weeks anyway). For the while, I'm wondering what to use for the name of the real C++ book.

 * They should have a vote just like Ada Programming (Talk:Ada Programming/New Name needed) did - but they did not Panic just renamed without consulting the other programmers. I have not pointed that out to him yet because I don't want to loose him as a contributer by nagging him all the time.

I was under the impression that "Programming:" was just our idea of a namespace, so a book called "Programming:Java" is really just named "Java" and is in the "Programming:" namespace. This is the route I've taken with some "Computer Science:" books. (Likely the "Programming" module itself should go away, since it's really just a bookshelf or is far too general to be a single book.) I'd like the C++ book to match the pattern of other PL books, which all seem to be "Programming:X", except for our flagship book on Ada. What do you suggest going forward? Thanks. MShonle 19:39, 10 September 2005 (UTC)

Yes - but the Bookshelf:Book idea has been found to inflexible is is now a WB:NP and as such unsuitable for new book or renames. It actualy fits very well with the may-be Policy/Vote rule - there are lots of ''eternal stubs'# in Programming.

font size in tables
You can resize the font with CSS. You might have to adjust the line-height style as well since it seems that the tables don't adjust correctly otherwise. Kellen T 18:21, 18 September 2005 (UTC)

WB:NP
I see, you are eager to change naming conventions in programming books. But you should understand, it's not so easy.

Today, many of programming books use space convention: Programming:Perl Variables. I understand it's really bad, but programming books widely use prognav - a convenient navigation template. The template applies only to space convention-named books. Besides renaming whole books, you would have to replace the template in every single chapter or change the template and rename every book using it.

I don't agree we should use slash convention. As I wrote before, it creates unnecessary links, duplicating navigational templates, and confuses readers. You mentioned problems with statistics - you're right, but, hey, who are the statistics for? For us. We shouldn't complicate everything just so that statistics look pretty. Anyway, does anyone use statistics?

I believe we should leave big existing programming books (like Programming:Perl) with wrong naming convention as they are now. There's no sense putting lots of effort only to rename them; I think it's better to write new chapters or enhance existing.

 * I guess I have a different opinion on big - working on a 200 chapter book (Ada Programming)

But I agree that new books should follow naming policy. It's worth considering to correct new books or existing, but very short, having no navigatinal template yet (like Programming:Pascal). I can make new template like prognav, using semicolon (IMO best suitable for Programming: books) convention (and looking much better).

And another thing: according to current naming policy, using bookshelf information like Programming: is depreciated. Should we rename new books from f.e. Programming:Nemerle to Nemerle?

 * Renaming is optional - but yes: Booknames should be something like Ada Programming instead of Programming:Ada

If you want, we can move this discussion to Staff lounge so that other Wikibookians could write their opinions. --Derbeth 09:11, 11 October 2005 (UTC)

 * This has been discussed several times - I just wanted to make some suggestions.

Wikiversity Vote
I fixed my page Klingoncowboy4 03:39, 20 October 2005 (UTC)

adminship
I was looking at your recent contributions and I wonder, why are you still not a sysop? As far as I can see you are active in Wikibooks cleanup and you know Wikibooks policies well. What's the reason? --Derbeth talk 22:39, 15 November 2005 (UTC)

 * None at all. I just feel a bit shy about nominating myself. --Krischik T 09:25, 16 November 2005 (UTC)

Are you willing to become an administrator? I can nominate you or ask other admin to do it. --Derbeth talk 09:27, 16 November 2005 (UTC)

 * Shure - I would be willing ;-). --Krischik T 10:15, 16 November 2005 (UTC)

Ok, I'd like to ask you some questions. Are you familiar with sysop's tools available at Wikibooks? Do you know current policies? Do you have time to patrol Recent changes and fight vandalism? Do you know how to solve copyright violation problems and which image licenses should and should not be used in uploaded files? --Derbeth talk 11:31, 16 November 2005 (UTC)

 * sysop's tools: you are never familar with any tool until you can actualy use them. But I heard of them. And especialy the one click revert was something I have missed several times.
 * current policies: I try to keep up to date with them and suggest them to other users.
 * vandalism: I fight it whenever I see it. I check the "changes" of user in question as well and follow him up.
 * copyright violation : put up the copyright violation notice wait a week and delete. That much for the theory - the praxis will be a lot more complicated but then one can allways read it up at [Wikibooks:Copyrights] when the problem arises.
 * images : just read that one up [Wikibooks:Image use policy] ;-)

 * Generaly I go with the German saying: "Man muss nicht wissen wie es geht - man muss nur wissen wo es steht." --Krischik T 12:04, 22 November 2005 (UTC)

Just a few more questions. How often do you plan to check recent changes (in days per week)? Do you read Staff lounge? Recently we have some controversies about Wikibooks mission and policies, you probably have noticed it. Are you interested in this issue? I also would like to know your opinion about Jokebook, White Heritage Security and Naturism listed (now or recently) on WB:VFD. Can you write here a short comment about each of these three books? --Derbeth talk 20:46, 22 November 2005 (UTC)

 * If possible I will have a look at recent changes every day. Times of high workload and holidays wont coun't - so that leaves an avarage of 5 days a week.

 * Yes indeed I am interested in the Wikibooks mission and policies. See for example Talk:FAQ_for_alt.internet.wireless.

 * Two of the books are delete so I can't read them. Still:
 * Jokebook : I think it would be akzeptable as an annotated text. But just a collection of jokes is not enough - give more time to develop.
 * White Heritage Security : sound's like it was a politial soapbox - delete.
 * Naturism : In theory there could be a textbook on Naturism but from the discussion I feel the book failed the aim - delete.

I have no further quistions. Discussion at WB:RFA has been just opened, good luck! --Derbeth talk 18:17, 24 November 2005 (UTC)

Learning to be an Admin
You have to learn a few good habits - like always checking "what links here". This is subpage of Wikiversity (and should be renamed). You can leave this page - I don't think it harmful. --Derbeth talk 14:18, 2 December 2005 (UTC)

Congrats
Congrats on Adminship. Use your super-powers wisely. Cheers. -- LV (Dark Mark) 14:25, 2 December 2005 (UTC)

Bookkeeping
I saw you deleted bookkeeping. It was said to be transwikied, but have you checked it? The problem is that you deleted text leaving unlinked images. Furthermore, these images were not present at Wikisource. I copied them and deleted from Wikibooks so hopefully everything is fine now, but keep it in mind in the future. --Derbeth talk 19:19, 4 January 2006 (UTC)

 * I checked Wikisource, the page history and user which requested the delete. I did indeed noticed that the pictures are missing but as the request was made by one (or even the) book author of the book so I expected the author to fix that later.
 * --Krischik T 07:18, 5 January 2006 (UTC)

Idea for a Program...
Hello, I have an idea for a small, simple program that would help many. Some people like to erase their Google usenet histories, but it is time consuming to look up every message you've ever posted and code in each  into their "automatic" removal tool here:

http://services.google.com:8882/urlconsole/controller?cmd=reload&lastcmd=login

Is there anyway to write a program that searches for all messages by your e-mail address, compiles a list of message IDs, then feeds that list into Google's tool?

I think a lot of people would use this. What language would you use to code this?

Thanks!

-Ian

Deleting Templates
Should i get old useless/unusable templates deleted or should i just blank them (assuming no good redirect)? For example Template:MapleStoryArmorTOC -- Prod-You 00:23, 9 January 2006 (UTC)

Rueda de Casino
You said that the Rueda de Casino book was an orphaned chapter, but it is a book. It has a number of subpages etc. The proposed policy on naming conventions doesn't seem to suggest any change to it. If you do decide to move it, take a look at the templates it uses carefully first, they're probably quite fragile.

Template:Cleanup-NC
I don't understand change you made to this template.

 * Prehaps I a wrong - but I think that cleanup templates should have a place where one can make a small descriptions of what needs doing. Not all problems are clean cut and easy to spot. In Nutrition only the reference chapters at the 2nd level are at fault. Looking at the main page and you would never know what's wrong. Just adding the template is not enough to know where the problems lies.

BTW, take a look at WB:RFA, we could use a bot instead of inserting 'rename' templates.

 * The authors of the book in question need to decide how to structure there book before we can let the boot loose.
 * Ok, but if we have such bot, book authors would be able to rename books easier. In addition: there are some dead, inactive Wikibooks. Will you wait a year until one of authors visits Wikibooks to rename the book? --Derbeth talk 08:36, 19 January 2006 (UTC)

 * Sorry, I forgot to log in. --Derbeth talk 08:30, 19 January 2006 (UTC)

Re: Ada Programming/Algorithms/Intro
I'm sorry about deleting it. I thought it really was duplicate and abandoned. I apologize.

BTW, it would be nice to put a note to that effect on the talk page as well if you are planning on using it through transclusion without being a template. A small thing, but it would prevent another admin from doing the same thing that I did. --Rob Horning 20:55, 1 February 2006 (UTC)

delete
Where I haven't given a reason, the reason is "useless redirect". Maybe I'll develop a new template that inserts that reason automatically, ~

Prolog
Could you please check the new version? Matusz 09:35, 21 February 2006 (UTC)

Well, ummm, maybe the problems are caused by much bigger audience of the wikipedia. It's not that easy to change the way you shape your thoughts. I'm a long time wikipedia user, and only very seldom do I contribute to other subprojects, as you've probably guessed. Anyway - there is a new phrasing and I hope it's not worse than the previous one. --matusz 22:16, 4 March 2006 (UTC)

Blocking conflict
If you block an IP, click "Block log" link to check if it wasn't blocked before. If there are two blocks on the same IP or user, only shorter one is valid. --Derbeth talk 22:14, 2 March 2006 (UTC)

WikiBooks Setup
How do I make / in titles work in a plain Wikimedia site as it does here ? Which feature ? Is it one of the MediaWiki variables ? I am Admin at my Wiki, I just don't know how to do it. I've been googling and searching Mediawiki.org for days w/o finding it, can you give me a hint ? Renmiri 18:51, 11 March 2006 (UTC)
 * I will ask the site admin. Thanks a million! Renmiri 15:13, 12 March 2006 (UTC)

PDF Versions page
Hi Krischik! Please see: http://en.wikibooks.org/wiki/Wikibooks:Staff_lounge#The_PDF_Versions_page RobinH 21:29, 12 March 2006 (UTC)

Help with German Wikibook
Hello I was wondering if you like to help with the development of the German Wikibook, it need much help and more activity, and since you area native German speaker, would you like to help?

--German Men92 17:43, 25 March 2006 (UTC)

Hit counters
Is there any way that a Wikibooks hit counter can be used on a sampling basis? I know that Wkibooks hit counters were removed but what I had in mind was including Wikibooks counters in a few chosen places for a week and then removing them so that we can gauge hit rates. This would not put excessive strain on the servers. RobinH 08:19, 12 April 2006 (UTC)

Typos
Do you mind if I correct some typos in your edit of the vote for collaboration of the month. I would normally just go ahead and correct typos, but these are kind of comments, so I thought is should ask. Dolive35 12:15, 24 April 2006 (UTC)

Bookshelf protection
A month ago, you protected five bookshelves. I think this does more harm than good, because some users can't add books they've created (contradictory to cleanup-link) and many users have bookshelves on their watchlist ready to revert user mistakes. Could you please unprotect these bookshelves, or at the very least make the editing approval consistent across all bookshelves. Thanks and regards, haginძaz 07:52, 10 May 2006 (UTC)

Haskell and types
Hello there! I'm not too sure what we should do about the Haskell and types line. If you glance at the wikibook, you'd see that nearly half of it is fundamentally about types in one way or another (consider the fun with types section on the bottom part of the advanced side). That's why I ended up not giving a link to a specific subpage... -- Kowey 04:53, 25 July 2006 (UTC)

General voting rules/Proposal
I want to call the attention of all wikibookians, especially active admins to the discussion about the new voting policy. Wikibooks currently does not have a concrete voting policy in effect, so the adaptation of this policy will potentially create immediate differences in the way business is conducted here. Due to large amounts of discussion, changes, and dissention, there are several versions of this policy being considered:

 * Version 1 Written by User:Whiteknight
 * Version 2 Written by User:Jguk
 * Version 3 User:RobinH's revision of Jguk's version
 * Version 4 Written by User:Kellen
 * Version 5 Whiteknight's Revision of Kellen's Version.

Also, there are additional issues being discussed, such as the inclusion of a "minimum contributions" clause, that will limit users with less then 20 votes from editing. Also, there is a proposed clause that would allow this 20 vote minimum to be raised in response to abuse.

I am sending this same message to all currently active admins. I hope you are able to come in and give your opinions on this matter. --Whiteknight (talk) (projects) 20:48, 11 August 2006 (UTC)

Help
There's been allot of mumfum page moves! By User:Пенис - Special:Contributions/Пенис, can you block him and revet his page moves. A regular user can't do it without deleting the redirect pages. --Az1568 07:29, 18 December 2006 (UTC)

Thanks for blocking him! here's a list of pages that were moved (List}. I've reverted some of them, but most of them need to be moved by a sysop. --Az1568 07:43, 18 December 2006 (UTC)

Ada Print Version
Do you know who the "main guy" is behind the ADA book? Just wondering if there is any major contributor who is helping out and stuff. I'm making a LaTeX version of the ADA book, and I'm changing a couple of things around so that things are better suited for the LaTeX version. If the project is leaderless, that is fine. I'll just be bold and merge my changes as they come (kind of how I've been doing it so far :-p).

As for specific changes to the print version so far, I'm going to focus on GNAT instead of the other ones. The other sections seem useful in a list, but are too stubby IMO to go into a printed book. --Dragontamer 08:14, 30 December 2006 (UTC)

Ada Programming lounge
Hi, I've posted a couple of new topics in the Talk:Ada Programming/Contributors lounge, maybe you want to contribute. Cheers, —surueña 17:59, 29 May 2008 (UTC)

Transclusion
Hi Martin. Take a loot at Reading_room/General. I undid the deletion of the transclusion by Panic2k4 from some of the pages you started. I don't know whether it is better to share the contents or copy the contents: in any case I undid his edits because he deleted them. I wanted to warn you about this discussion so you can participate on it, given that the idea of transclusion among basics on programming languages was yours. --ManuelGR (talk) 11:02, 20 December 2008 (UTC)

Removal of admin tools due to inactivity
You have been nominated for having your administrative tools removed due to the policy on inactivity. If you wish to contest this, please visit Wikibooks:Requests for permissions. -- Adrignola talk contribs 16:54, 28 November 2009 (UTC)

title: User talk:Krischik


text:
User:ManuelGR

Hi.

My main interest for the moment in Wikibooks is to help a bit with the Ada Programming book.

For further information see my pages on Wikipedia: es, en and Wikibooks: es.

Thanks to all that have supported my proposal of activating subpages in the Wikibooks main namespace. See Wikibooks should use subpages.

Useful things (at least for me, they are)

 * awb.el: this is an Emacs Lisp module that I use for adding the code and link templates to the Ada Programming pages.

(Outdated) proposals

 * /Centralized development status proposal/

es:Usuario:ManuelGR

title: User:ManuelGR


text:
German/Grammar

გერმანული ენა/გრამატიკა

title: German/Grammar