|
|
| Line 1: |
Line 1: |
| {{PD Help Page}}
| | == Description == |
| '''Range blocks''' are technical restrictions applied through [[Special:Block]] to a group of [http://en.wikipedia.org/wiki/IP_addresses IP addresses] that prevent them from editing, creating new accounts, sending email through the wiki interface, et cetera. Registered accounts editing from these IP addresses will also be blocked, unless you check the box to only block anonymous editors.
| |
|
| |
|
| Range blocking is enabled on all [http://en.wikipedia.org/wiki/Wikimedia_Foundation Wikimedia] wikis; to enable it on other wikis, add "<code>{{mediawiki|Manual:$wgSysopRangeBans|$wgSysopRangeBans}} = true;</code>" in <tt>{{mediawiki|Manual:LocalSettings.php|LocalSettings.php}}</tt>.
| | Funtoo Linux has a number of forked packages, and sometimes these packages can get out-of-date relative to Gentoo Linux. Periodically, we need to update ebuilds in Funtoo Linux so that they are current. To make this task easier, we have an automated script that compares versions of forked ebuilds in Funtoo Linux to those in Gentoo Linux. |
|
| |
|
| To block an IP range from [[Special:Block]], enter the first IP address in the range followed by a forward slash and a [http://en.wikipedia.org/wiki/Classless_inter-domain_routing Classless inter-domain routing] (CIDR) suffix. '''You should avoid performing range blocks unless you understand what you are doing, or you may end up blocking tens of thousands of people who are not the problem!'''
| | Here's how it works: Below, you can see a list of all ebuilds in Gentoo Linux that have higher version numbers than those in Funtoo Linux. This list is updated ''hourly''. |
| | {{#get_web_data:url=http://ports.funtoo.org/my.json|format=json|data=fcx8664=fcx8664}} |
| | == Funtoo / Gentoo Comparison (funtoo-current, x86-64bit) == |
| | |
| | {{#arraymaptemplate:{{#external_value:fcx8664}}|PkgCompareDisplay|,||}} |
|
| |
|
| ==Non-technical explanation==
| | Some of these ebuilds may be intentionally kept at earlier versions, although in general, we want to update ebuilds to the most recent version that works reliably. Here are some technical caveats: |
| IP address are broken up into blocks of numbers. The most common block is 256 numbers. An example of this would be <tt>148.20.57.0</tt> thru <tt>148.20.57.255</tt>. Once it reaches <tt>255</tt> the next number is <tt>148.20.58.0</tt>.
| |
|
| |
|
| IP addresses can be broken up in to smaller or larger blocks. The smallest practical block is a block of 4. This could be one of the following:
| | * Rev parts of ebuilds ("<tt>-rX</tt>") are not considered in version comparisons, since sometimes Gentoo and Funtoo revisions are not analogous. |
| | * Masks are not used for this version comparison. The latest unmasked or masked version in Gentoo is compared against the latest masked or unmasked version in Funtoo. |
|
| |
|
| :<tt>148.20.57.0 - 148.20.57.3</tt>, or
| | == How To Help == |
| :<tt>148.20.57.4 - 148.20.57.7</tt>, or
| |
| :<tt>148.20.57.8 - 148.20.57.11</tt>, etc.
| |
|
| |
|
| Of each block of 4 numbers, only two can be assigned to a computer. The first and last numbers of any block are reserved for network communication. These are level 30 blocks and can be expressed like this:
| | Here's how you can help: If you see an package above that appears to be out-of-date, and you believe we should update to a newer version, [http://bugs.funtoo.org open a bug] on the Funtoo bug tracker. We can look into the ebuild and will give you feedback on whether we feel a new version of the ebuild should be added. |
|
| |
|
| :<tt>148.20.57.0/30</tt>, or
| | If there is some consensus that it should be updated, then generally Funtoo staff will update the ebuild for you, since generally we are familiar with why the ebuild was forked and be able to efficiently update the package to the most recent version. |
| :<tt>148.20.57.4/30</tt>, or
| |
| :<tt>148.20.57.8/30</tt>, etc.
| |
|
| |
|
| The next largest block is 8. They can be as follows: | | However, in some cases it may be possible for you can also help with the update process, if you are so inclined, by forking the [https://github.com/funtoo/funtoo-overlay funtoo-overlay on GitHub] and working on updating the ebuild yourself. Reference your commits in a bug report on our bug tracker. If you are going to help with ebuild writing, it's important to first familiarize yourself with why we forked the ebuild in the first place. The best way to dig up information on the history of the forked Funtoo package is to type "<tt>git log .</tt>" in the ebuild directory. This will show log information for the package only, and you can look at the history of the ebuild. |
|
| |
|
| :<tt>148.20.57.0 - 148.20.57.7</tt>, or
| | When updating ebuilds, we do want to look at Gentoo's most recent changes. Some of our ebuilds are mild variations of Gentoo's ebuilds, while others are complete rewrites. In general, we like to make our work as easy as possible, so we don't want to duplicate work, although sometimes there are exceptions where we will rewrite complex core ebuilds to make them more ''maintainable'' and ''easy to understand'' (our <tt>sys-devel/gcc</tt> ebuilds are an example of this.) |
| :<tt>148.20.57.8 - 148.20.57.15</tt>, or
| |
| :<tt>148.20.57.16 - 148.20.57.23</tt>, etc.
| |
|
| |
|
| In this block of 8 numbers only 6 can be assigned to a computer as, once again, the first and last numbers in a block are reserved for network communication. These can also be expressed as follows:
| | Of course, there's a reason we originally forked an ebuild, and we want to make the process of updating ebuilds as easy as possible. Sometimes, we will fork a package from Gentoo for a specific reason, such as a build breakage, and once the issue is resolved upstream, we will want to ''unfork'' the package by removing it from funtoo-overlay entirely. In general, we want to minimize the number of forked ebuilds to the minimum number necessary. |
|
| |
|
| :<tt>148.20.57.0/29</tt>, or
| | [[Category:Activity]] |
| :<tt>148.20.57.8/29</tt>, or
| |
| :<tt>148.20.57.16/29</tt>, etc.
| |
| | |
| From this point on, the number of IP addresses in a block continue to double: 16, 32, 64, 128, 256, etc.
| |
| | |
| :A block of 16 would start <tt>148.20.57.0/28</tt>.
| |
| :A block of 32 would start <tt>148.20.57.0/27</tt>.
| |
| :A block of 64 would start <tt>148.20.57.0/26</tt>.
| |
| :A block of 128 would start <tt>148.20.57.0/25</tt>.
| |
| :A block of 256 would start <tt>148.20.57.0/24</tt>.
| |
| | |
| So if you have an IP address and you want to block the range assigned how do you know which one to use?
| |
| Let's say you have a problem with <tt>148.20.57.34</tt>. You can lookup who has this IP address at http://ws.arin.net/whois/?queryinput=148.20.57.34.
| |
| Say this tells us that this IP address is assigned, along with a LOT of others in a <tt>/17</tt> range, to the Department of Defense. We certainly don't want to block a large block of the DoD! The rule of thumb is block as little as possible. Only block a range if there is a cluster of IP addresses giving a problem.
| |
| | |
| There's a calculator that is very useful for this:
| |
| http://www.csgnetwork.com/ipinfocalc.html.
| |
| Go to this site and enter <code>148.20.57.34</code> into the first set of blanks. Now select Network Prefix Length and enter <code>27</code> (this will give a block of 32 addresses) and click Calculate Network Information. This will show us a block of 32 IP addresses that include <tt>148.20.57.34</tt>. (The first - network - and the last - broadcast - addresses will be displayed along with the usable addresses in the range.) You can use this tool to test ranges to be sure they are what you want before entering the information to initiate the block.
| |
| | |
| ==Technical explanation==
| |
| CIDR notation is written as the IP address, a slash, and the CIDR suffix (for example, the IPv4 "<tt>10.2.3.41/24</tt>" or IPv6 "<tt>a3:b:c1:d:e:f:1:21/24</tt>"). The CIDR suffix is the number of starting digits every IP address in the range have in common when written in binary.
| |
| | |
| For example: "<tt>10.10.1.32</tt>" is binary "<tt>00001010.00001010.00000001.00100000</tt>", so <tt>10.10.1.32/27</tt> will match the first 27 digits ("<tt><u>00001010</u>.<u>00001010</u>.<u>00000001</u>.<u>001</u>00000</tt>"). The IP addresses <tt>10.10.1.32</tt>–<tt>10.10.1.63</tt>, when converted to binary, all have the same 27 first digits and will be blocked if <tt>10.10.1.32/27</tt> is blocked.
| |
| | |
| As the CIDR suffix increases, the block affects fewer IP addresses (see [[#Table|table of sample ranges]]). CIDR suffixes are not the same for IPv4 addresses as they are for IPv6 addresses.
| |
| | |
| ==Calculating the CIDR suffix==
| |
| You can use the [[#Table|table of sample ranges]] below to guess the range, use a computer script, or manually calculate the range.
| |
| | |
| ===Conversion to binary===
| |
| The first step in manually calculating a range is to convert the first and last IP address to binary representation. (This assumes you're not using a computer script, which can probably calculate the range for you anyway.) An IP address is composed of four groups of eight ones and zeros. Each group represents a number from 0 to 255. To convert a number to binary, you can use a [http://www.ccci.com/tools/subcalc/binary.html reference table] or know the value of each binary digit:
| |
| | |
| :<tt>Binary digit: 1 1 1 1 1 1 1 1</tt>
| |
| :<tt>Value: 128 64 32 16 8 4 2 1</tt>
| |
| | |
| Proceeding from left to right, fill in <tt>1</tt> if the number is at least that value, and subtract that value (if it's not, fill in <tt>0</tt> and don't subtract). For example, to calculate 240:
| |
| # 240 is at least 128, so place <tt>1</tt> and subtract 128.
| |
| # 112 (240-128) is at least 64, so place <tt>1</tt> and subtract 64.
| |
| # 48 (112-64) is at least 32, so place <tt>1</tt> and subtract 32.
| |
| # 16 (48-32) is at least 16, so place <tt>1</tt> and subtract 16.
| |
| # Since the remaining value is zero, all the remaining places are <tt>0</tt>.
| |
| Thus, 240 is <tt>1111 0000</tt> because it can be represented as 128+64+32+16+0+0+0+0.
| |
| | |
| ===Calculate range===
| |
| # Place both IP addresses one atop the other, and count how many starting digits are exactly alike. This is the CIDR suffix.
| |
| # Double-check! Being off by one digit could extend your block by thousands of addresses.
| |
| | |
| The example below calculates the CIDR range between <tt>69.208.0.0</tt> and <tt>69.208.0.255</tt>. Note that this is a simple example; some groups of IP addresses do not so neatly fit CIDR suffixes, and need multiple different-sized blocks to block the exact range.
| |
| | |
| :IP addresses:
| |
| :<tt> 69.208.0.0</tt>
| |
| :<tt> 69.208.0.255</tt>
| |
| | |
| :Convert to binary:
| |
| :<tt> 0100 0101.1101 0000.0000 0000.0000 0000</tt>
| |
| :<tt> 0100 0101.1101 0000.0000 0000.1111 1111</tt>
| |
| | |
| :Count identical first numbers:
| |
| :<tt> '''0100 0101.1101 0000.0000 0000'''.0000 0000</tt>
| |
| :<tt> '''0100 0101.1101 0000.0000 0000'''.1111 1111</tt>
| |
| :<tt> |____________________________|</tt>
| |
| :<tt> 24 digits</tt>
| |
| | |
| :CIDR range:
| |
| :<tt> 69.208.0.0/24</tt>
| |
| | |
| ===<span id="Table">Table of sample ranges</span>===
| |
| The table below shows the IP blocks each CIDR suffix affects. Note that MediaWiki only supports blocking CIDR suffixes 16–32.
| |
| | |
| {| class="wikitable" align=center
| |
| ! CIDR
| |
| ! Start Range
| |
| ! End Range
| |
| ! Total addresses
| |
| ! Bits selected in IP address
| |
| |- style="color:gray;"
| |
| | <tt>69.208.0.0'''/0'''</tt>
| |
| | <tt>0.0.0.0</tt>
| |
| | <tt>255.255.255.255</tt>
| |
| | align=right | 4,294,967,296
| |
| | <tt>********.********.********.********</tt>
| |
| |- style="color:gray;"
| |
| | <tt>69.208.0.0'''/1'''</tt>
| |
| | <tt>0.0.0.0</tt>
| |
| | <tt>127.255.255.255</tt>
| |
| | align=right | 2,147,483,648
| |
| | <tt>0*******.********.********.********</tt>
| |
| |- style="color:gray;"
| |
| | <tt>69.208.0.0'''/4'''</tt>
| |
| | <tt>64.0.0.0</tt>
| |
| | <tt>79.255.255.255</tt>
| |
| | align=right | 268,435,456
| |
| | <tt>0100****.********.********.********</tt>
| |
| |- style="color:gray;"
| |
| | <tt>69.208.0.0'''/8'''</tt>
| |
| | <tt>69.0.0.0</tt>
| |
| | <tt>69.255.255.255</tt>
| |
| | align=right | 67,108,864
| |
| | <tt>01000101.********.********.********</tt>
| |
| |- style="color:gray;"
| |
| | <tt>69.208.0.0'''/11'''</tt>
| |
| | <tt>69.208.0.0</tt>
| |
| | <tt>69.238.255.255</tt>
| |
| | align=right | 2,197,152
| |
| | <tt>01000101.110*****.********.********</tt>
| |
| |- style="color:gray;"
| |
| | <tt>69.208.0.0'''/12'''</tt>
| |
| | <tt>69.208.0.0</tt>
| |
| | <tt>69.223.255.255</tt>
| |
| | align=right | 1,048,576
| |
| | <tt>01000101.1101****.********.********</tt>
| |
| |- style="color:gray;"
| |
| | <tt>69.208.0.0'''/13'''</tt>
| |
| | <tt>69.208.0.0</tt>
| |
| | <tt>69.215.255.255</tt>
| |
| | align=right | 524,288
| |
| | <tt>01000101.11010***.********.********</tt>
| |
| |- style="color:gray;"
| |
| | <tt>69.208.0.0'''/14'''</tt>
| |
| | <tt>69.208.0.0</tt>
| |
| | <tt>69.211.255.255</tt>
| |
| | align=right | 262,144
| |
| | <tt>01000101.110100**.********.********</tt>
| |
| |- style="color:gray;"
| |
| | <tt>69.208.0.0'''/15'''</tt>
| |
| | <tt>69.208.0.0</tt>
| |
| | <tt>69.209.255.255</tt>
| |
| | align=right | 131,072
| |
| | <tt>01000101.1101000*.********.********</tt>
| |
| |-
| |
| | <tt>69.208.0.0'''/16'''</tt>
| |
| | <tt>69.208.0.0</tt>
| |
| | <tt>69.208.255.255</tt>
| |
| | align=right | 65,536
| |
| | <tt>01000101.11010000.********.********</tt>
| |
| |-
| |
| | <tt>69.208.0.0'''/17'''</tt>
| |
| | <tt>69.208.0.0</tt>
| |
| | <tt>69.208.127.255</tt>
| |
| | align=right | 32,768
| |
| | <tt>01000101.11010000.0*******.********</tt>
| |
| |-
| |
| | <tt>69.208.0.0'''/18'''</tt>
| |
| | <tt>69.208.0.0</tt>
| |
| | <tt>69.208.63.255</tt>
| |
| | align=right | 16,384
| |
| | <tt>01000101.11010000.00******.********</tt>
| |
| |-
| |
| | <tt>69.208.0.0'''/19'''</tt>
| |
| | <tt>69.208.0.0</tt>
| |
| | <tt>69.208.31.255</tt>
| |
| | align=right | 8,192
| |
| | <tt>01000101.11010000.000*****.********</tt>
| |
| |-
| |
| | <tt>69.208.0.0'''/20'''</tt>
| |
| | <tt>69.208.0.0</tt>
| |
| | <tt>69.208.15.255</tt>
| |
| | align=right | 4,096
| |
| | <tt>01000101.11010000.0000****.********</tt>
| |
| |-
| |
| | <tt>69.208.0.0'''/21'''</tt>
| |
| | <tt>69.208.0.0</tt>
| |
| | <tt>69.208.7.255</tt>
| |
| | align=right | 2,048
| |
| | <tt>01000101.11010000.00000***.********</tt>
| |
| |-
| |
| | <tt>69.208.0.0'''/22'''</tt>
| |
| | <tt>69.208.0.0</tt>
| |
| | <tt>69.208.3.255</tt>
| |
| | align=right | 1,024
| |
| | <tt>01000101.11010000.000000**.********</tt>
| |
| |-
| |
| | <tt>69.208.0.0'''/23'''</tt>
| |
| | <tt>69.208.0.0</tt>
| |
| | <tt>69.208.1.255</tt>
| |
| | align=right | 512
| |
| | <tt>01000101.11010000.0000000*.********</tt>
| |
| |-
| |
| | <tt>69.208.0.0'''/24'''</tt>
| |
| | <tt>69.208.0.0</tt>
| |
| | <tt>69.208.0.255</tt>
| |
| | align=right | 256
| |
| | <tt>01000101.11010000.00000000.********</tt>
| |
| |-
| |
| | <tt>69.208.0.0'''/25'''</tt>
| |
| | <tt>69.208.0.0</tt>
| |
| | <tt>69.208.0.127</tt>
| |
| | align=right | 128
| |
| | <tt>01000101.11010000.00000000.0*******</tt>
| |
| |-
| |
| | <tt>69.208.0.0'''/26'''</tt>
| |
| | <tt>69.208.0.0</tt>
| |
| | <tt>69.208.0.63</tt>
| |
| | align=right | 64
| |
| | <tt>01000101.11010000.00000000.00******</tt>
| |
| |-
| |
| | <tt>69.208.0.0'''/27'''</tt>
| |
| | <tt>69.208.0.0</tt>
| |
| | <tt>69.208.0.31</tt>
| |
| | align=right | 32
| |
| | <tt>01000101.11010000.00000000.000*****</tt>
| |
| |-
| |
| | <tt>69.208.0.0'''/28'''</tt>
| |
| | <tt>69.208.0.0</tt>
| |
| | <tt>69.208.0.15</tt>
| |
| | align=right | 16
| |
| | <tt>01000101.11010000.00000000.0000****</tt>
| |
| |-
| |
| | <tt>69.208.0.0'''/29'''</tt>
| |
| | <tt>69.208.0.0</tt>
| |
| | <tt>69.208.0.7</tt>
| |
| | align=right | 8
| |
| | <tt>01000101.11010000.00000000.00000***</tt>
| |
| |-
| |
| | <tt>69.208.0.0'''/30'''</tt>
| |
| | <tt>69.208.0.0</tt>
| |
| | <tt>69.208.0.3</tt>
| |
| | align=right | 4
| |
| | <tt>01000101.11010000.00000000.000000**</tt>
| |
| |-
| |
| | <tt>69.208.0.0'''/31'''</tt>
| |
| | <tt>69.208.0.0</tt>
| |
| | <tt>69.208.0.1</tt>
| |
| | align=right | 2
| |
| | <tt>01000101.11010000.00000000.0000000*</tt>
| |
| |-
| |
| | <tt>69.208.0.0'''/32'''</tt>
| |
| | <tt>69.208.0.0</tt>
| |
| | <tt>69.208.0.0</tt>
| |
| | align=right | 1
| |
| | <tt>01000101.11010000.00000000.00000000</tt>
| |
| |}
| |
| | |
| ==References==
| |
| * [[wikipedia:Classless Inter-Domain Routing|Classless Inter-Domain Routing]]
| |
| | |
| ==External links==
| |
| * [http://www.find-ip-address.org/ip-country/ IP Address Ranges Block] gives you complete IP ranges for certain countries.
| |
| * [http://apps.csc.fi/laskin2.html Netmask calculator] which helps in making the correct decision for range blocks.
| |
| * [http://tools.wikimedia.de/~chm/blockcalc.php Rangeblock-Calculator] gives you the range you should use when blocking.
| |
| | |
| {{Languages|Help:Range blocks}}
| |
| | |
| [[Category:Help|Range blocks]]
| |
| [[Category:Block|Range blocks]] | |
Description
Funtoo Linux has a number of forked packages, and sometimes these packages can get out-of-date relative to Gentoo Linux. Periodically, we need to update ebuilds in Funtoo Linux so that they are current. To make this task easier, we have an automated script that compares versions of forked ebuilds in Funtoo Linux to those in Gentoo Linux.
Here's how it works: Below, you can see a list of all ebuilds in Gentoo Linux that have higher version numbers than those in Funtoo Linux. This list is updated hourly.
Error while fetching data from URL http://ports.funtoo.org/my.json: $2.
Error fetching URL: Failed to connect to ports.funtoo.org port 80: No route to host
There was a problem during the HTTP request: 0 Error
Could not get URL http://ports.funtoo.org/my.json after 3 tries.
Funtoo / Gentoo Comparison (funtoo-current, x86-64bit)
Some of these ebuilds may be intentionally kept at earlier versions, although in general, we want to update ebuilds to the most recent version that works reliably. Here are some technical caveats:
- Rev parts of ebuilds ("-rX") are not considered in version comparisons, since sometimes Gentoo and Funtoo revisions are not analogous.
- Masks are not used for this version comparison. The latest unmasked or masked version in Gentoo is compared against the latest masked or unmasked version in Funtoo.
How To Help
Here's how you can help: If you see an package above that appears to be out-of-date, and you believe we should update to a newer version, open a bug on the Funtoo bug tracker. We can look into the ebuild and will give you feedback on whether we feel a new version of the ebuild should be added.
If there is some consensus that it should be updated, then generally Funtoo staff will update the ebuild for you, since generally we are familiar with why the ebuild was forked and be able to efficiently update the package to the most recent version.
However, in some cases it may be possible for you can also help with the update process, if you are so inclined, by forking the funtoo-overlay on GitHub and working on updating the ebuild yourself. Reference your commits in a bug report on our bug tracker. If you are going to help with ebuild writing, it's important to first familiarize yourself with why we forked the ebuild in the first place. The best way to dig up information on the history of the forked Funtoo package is to type "git log ." in the ebuild directory. This will show log information for the package only, and you can look at the history of the ebuild.
When updating ebuilds, we do want to look at Gentoo's most recent changes. Some of our ebuilds are mild variations of Gentoo's ebuilds, while others are complete rewrites. In general, we like to make our work as easy as possible, so we don't want to duplicate work, although sometimes there are exceptions where we will rewrite complex core ebuilds to make them more maintainable and easy to understand (our sys-devel/gcc ebuilds are an example of this.)
Of course, there's a reason we originally forked an ebuild, and we want to make the process of updating ebuilds as easy as possible. Sometimes, we will fork a package from Gentoo for a specific reason, such as a build breakage, and once the issue is resolved upstream, we will want to unfork the package by removing it from funtoo-overlay entirely. In general, we want to minimize the number of forked ebuilds to the minimum number necessary.