Kali linux mirrors list

Kali linux mirrors list

The explanations below are of interest to you if you want to contribute a publicly accessible mirror and if you want to integrate it in one of the mirror redirectors (http.kali.org and cdimage.kali.org).

If you want run a private mirror, see the dedicated section at the end.

Requirements

To be an official Kali Linux mirror, you will need a web-accessible server (http required and https if possible too) with lots of disk space, good bandwidth, rsync, and SSH access enabled. As of early 2021, the main package repository is about 1.1 TB and the ISO images repository is about 120 GB but you can expect those numbers to grow regularly. A mirror site is expected to make the files available over HTTP and RSYNC so those services will need to be enabled. FTP access is optional.

Note on “Push Mirroring” — The Kali Linux mirroring infrastructure uses SSH-based triggers to ping the mirrors when they need to be refreshed. This currently takes place 4 times a day.

Create a User Account for the Mirror

If you don’t have yet an account dedicated for the mirrors, create such an account (here we call it “archvsync”):

Create Directories for the Mirror

Create the directories that will contain the mirrors and change their owner to the dedicated user that you just created:

Configure rsync

Next, configure the rsync daemon (enable it if needed) to export those directories:

Configure Your Mirror

Configuration of your web server and FTP server are outside the scope of this article. Ideally, you should export the mirrors at http://yourmirror.net/kali and http://yourmirror.net/kali-images (and do the same for the FTP protocol, if you’re supporting it).

Now comes interesting part: the configuration of the dedicated user that will handle the SSH trigger and the actual mirroring. You should first unpack ftpsync.tar.gz in the user’s account:

Now we need to create a configuration file. We start from a template and we edit at least the MIRRORNAME, TO, RSYNC_PATH, and RSYNC_HOST parameters:

Set Up the SSH Keys

The last step is to setup the .ssh/authorized_keys file so that archive.kali.org can trigger your mirror:

If you have not unpacked the ftpsync.tar.gz in the home directory, then you must adjust accordingly the

/bin/ftpsync path, which is hard-coded in .ssh/authorized_keys .

Now you must send an email to devel@kali.org with all the details concerning your mirrors (including user/port to use for SSH push access, public hostname, etc.) so that you can be added in the main mirror list and so that we can open up your rsync access on archive.kali.org. Please indicate clearly who should be contacted in case of problems (or if changes must be made/coordinated to the mirror setup).

Instead of waiting for the first push from archive.kali.org, you should run an initial rsync with a mirror close to you, using the mirror list linked above to select one. Assuming that you picked ftp.halifax.rwth-aachen.de, here’s what you can run as your dedicated mirror user:

Set Up cron to Manually Mirror ISO Images

The ISO images repository does not use push mirroring so you must schedule a daily rsync run. We provide a bin/mirror-kali-images script, which is ready to use that you can add in the crontab of your dedicated user. You just have to configure etc/mirror-kali-images.conf.

Please adjust the precise time so that archive.kali.org doesn’t get overloaded by too many mirrors at the same time.

How to Set Up a Private Kali Linux Mirror

If you want to setup a private mirror, you can use the same tools as for the public mirror with the following differences:

you will not be able to use SSH push mirroring for the package repository, instead you have to put

/bin/ftpsync sync:archive:kali in the crontab of the user owning the mirror ( archvsync in the above explanation).

you must use a non-kali.org mirror as the source mirror, almost all of them offer public rsync access (kali.org servers are restricted)

Updated on: 2021-Sep-27
Author: g0tmi1k

Источник

Kali linux mirrors list

The topic of repositories is always a large one, and comes up frequently. It is an item which people often get wrong and confused with. Please take the time to read the information below and any references which is linked to before acting on anything.

Default Network Repository Value

On a standard, clean install of Kali Linux, with network access, you should have the following entry present in /etc/apt/sources.list :

If the output doesn’t exactly match up to the above output, you may not be able to install any new additional packages or receive updates. This may happen for any number of reasons, such as:

• You have switched your branch.
• Using a different hardcoded mirror.

You will probably want to read the “switching branches” section to alter this.

Since Kali 2020.3, after Kali’s setup is complete, network repositories will be enabled by default, even if there was no network access during installation.

Switching Branches/Regular Repositories

Kali has various different branches to choose from (please take the time to read which one would be the best option for your setup), and you may be able to switch or include additional repositories.

kali-rolling (Default & frequently updated):

kali-last-snapshot (Point release so more “stable” & the “safest”):

kali-experimental (Packages which are under testing — often used with the rolling repository):

Sources.list Format

• Archive is going to be deb (Regular Binary) or deb-src (Source), depending if you want a package or the source of the package.
• Mirror should be http.kali.org/kali as this is our load balancer, which will direct you to best mirror.
• Branch is what version of Kali you wish to use.
• Component is what packages you wish to use, based on the Debian Free Software Guidelines (DFSG). Kali defaults to everything.

Default Offline Install Values

During the Kali setup process, if you don’t have access to a network connection to reach a repository, you will perform an offline installation of Kali Linux. You will be limited to the packages & the version which is on the medium you installed Kali from. This will then configure Kali to continue to use this medium to install packages from, even after Kali has been installed.

This means you will not get any updates to packages, or any new additional tools, which can be frustrating. You can see if you the offline media enabled if your values match up with whats below (or if you want to enable this option):

If your output matches whats above, please see the switching branch section, if you wish to receive updates.

However, if you do have network connection, which has access to network repositories, it will be enabled for you. You don’t need to do anything.

Non-Kali Repositories

If you want to install additional tools and software (such as signal) outside of what Kali has to offer, you may need to include an extra repository for this to happen. Please do not alter /etc/apt/sources.list , as this is used for the Kali Linux Operating System. Any extra tools and software needs to be placed into their own file in the directory /etc/apt/sources.list.d/ (such as /etc/apt/sources.list.d/repo-name.list , replacing repo-name with the mirror name). It is highly recommended that each mirror should be in its own file.

By adding Kali’s repository to a non-Kali OS (such as trying to add Kali to Ubuntu), this will highly increase the chance of your system not working. It may not happen straight away, but without any warning, it may break. We will not be able to offer support (and based on what we have seen over the years, most other OS will not help too).

Likewise, adding other operating system’s repositories into Kali (such as trying to put Ubuntu on Kali), will break your installation. This is the single most common reason why Kali Linux systems break.

If any guides are telling you to do anything else than the above, this is unofficial advice, and completely not supported by Kali Linux. More often than not, users in this case end up doing a reinstall after learning this lesson.

Mirrors

We have a list of official Kali Linux mirrors, as well as a guide on how to setup your own. This may be kept as a local repository which is only accessible on a LAN, or a remote private one, or if you have the ability to, you may wish to share back to the community and make it public allowing for anyone else in your geographical area to benefit from it.

Source Repositories

By using a deb in the repositories, it will allow for binary packages to be downloaded. However, should you require the source to a package (so you can compile the package yourself if you so wish, or look into debugging a problem with a package), you can add deb-src as a extra line in the repositories.

We used kali-rolling for the branch above, but you can select any value you wish.

Updated on: 2021-Sep-27
Author: g0tmi1k

Источник

How to change repositories to a different mirror?

This is a guide on How to change repositories to a different mirror that applies to all Linux distributions. Often you would feel the auto selected mirror via GeoIP is not the fastest one of you’re just paranoid like me who would want to select a mirror from a specific country. This guide would help you to select mirrors manually and control where you download updates from. It might also help you speed up your download if you manage to select a good one.

I am not the original author of this guide, g0tmi1k from Kali Forums wrote it and it is a wonderful guide on how to change repositories to a different mirror.

I am redistributing this to make it more available in search engines as I too failed to find a well written guide on achieve this. I am not even going to try to re-write anything as this Guide is just too good. This was originally written for Kali Linux but any Linux user can find a mirror of their choice, and replace the links to point to their chosen mirror. Other distro users, feel free to leave a comment if you need help.

Original post link How to change the repositories to a different official mirror. Again kudos to gotli1lk for this great guide.

Related posts:

How to change repositories to a different mirror

There are several mirrors of the Kali Linux repository server, all of which are spread over the world.
Each time you interact with the repository, by default it will automatically use the mirror that is closest to you based on your geoip location (idea being, this will give you the best speed due to less latency).

For whatever reason, you may wish to manually force kali to use a certain/different mirror rather than the one that is nearest you.
Warning : Doing so, if that mirror stops functioning, you will no longer receive updates.

Find your mirror

To start with, you can see what mirror you’re using and other ones near by, by visiting this URL: http://http.kali.org/README.mirrorlist
For example:

…So from the looks of it, in this example ‘ftp.hands.com’ is being used. Lets switch to ‘kali.mirror.garr.it’
(there isn’t a reason or justification for this, just a server that was picked at random).

Make a backup of your sources.list file

Before making any modifications, its highly recommended that you create a backup of any files that will be altered.
This can be done by running:

Change mirror in sources.list file

The default source.list file looks like:

So we will replace default values with ‘kali.mirror.garr.it’.
From: http – README.mirrorlist we can see the base HTTP URL is: kali.mirror.garr.it/mirrors/kali/

From: security – README.mirrorlist we can see the base security URL is: kali.mirror.garr.it/mirrors/kali-security/

Therefore we can make the switch to ‘kali.mirror.garr.it’ by using the default values as a template, and merging in the information above.

Example command:

The result looks like this:

Test your change

We can then test it out by doing ‘apt-get update’:

Rollback changes

If anything goes wrong at any stage or the server isn’t working, we are able to restore from the backup by doing:

Источник

Adding Kali Linux mirrors after offline installation

If you installed Kali offline from a CD/DVD or USB (or have chosen not to connect to internet during installation), you probably have an empty sources.list file with just 2 lines on it (CDROM’s). Also if your internet connection is not reliable or too slow to do an update during install, you might’ve chosen a similar installation option. Either way, you won’t get the mirrors or repositories during a hard disk install added to your sources.list file. This will cause issues in the future when seeking new or updated software packages from the Kali repos.This guide shows how to add official Kali Linux mirrors or repositories.

Similar posts exists in this website to troubleshoot other problems which might be worth looking into:

Kali Linux sources.list Repositories page: Official Link

Open sources.list and comment all lines with # in front

Add Official Repo’s only:

Save and close the file.

You can check that the sources have been added and are being used by loading Add/Remove Software from the Sys Tools menu and selecting System -> Software Sources.

Clean your apt-get

STOP: If your Kali Linux apt-get update is slow follow this guide to sort out other issues: How to fix Kali apt-get slow update?

To switch repositories to a different mirror of your choice, follow this guide: How to change repositories to a different mirror?

Источник

Introduction to APT

September 30, 2017 by digip Comments are off

8.1. Introduction to APT

Let’s begin with some basic definitions, an overview, and some history about Debian packages, starting with dpkg and APT.

8.1.1. Relationship between APT and dpkg

A Debian package is a compressed archive of a software application. A binary package (a .deb file) contains files that can be directly used (such as programs or documentation), while a source package contains the source b for the software and the instructions required for building a binary package. A Debian package contains the application’s files as well as other metadata including the names of the dependencies the application needs, as well as scripts that enable the execution of commands at different stages in the package’s lifecycle (installation, upgrades, and removal).

The dpkg tool was designed to process and install .deb packages, but if it encountered an unsatisfied dependency (like a missing library) that would prevent the package from installing, dpkg would simply list the missing dependency, because it had no awareness or built-in logic to find or process the packages that might satisfy those dependencies. The Advanced Package Tool (APT ), including apt and apt-get, were designed to address these shortcomings and could automatically resolve these issues. We will talk about both dpkg and the APT tools in this chapter.

The base command for handling Debian packages on the system is dpkg, which performs installation or analysis of .deb packages and their contents. However, dpkg has only a partial view of the Debian universe: it knows what is installed on the system and whatever you provide on the command line, but knows nothing of the other available packages. As such, it will fail if a dependency is not met. APT addresses the limitations.

APT is a set of tools that help manage Debian packages, or applications on your Debian system. You can use APT to install and remove applications, update packages, and even upgrade your entire system. The magic of APT lies in the fact that it is a complete package management system that will not only install or remove a package, but will consider the requirements and dependencies of the packaged application (and even their requirements and dependencies) and attempt to satisfy them automatically. APT relies on dpkg but APT differs from dpkg, as the former installs the latest package from an online source and works to resolve dependencies while dpkg installs a package located on your local system and does not automatically resolve dependencies.

If you have been around long enough to remember compiling programs with gcc (even with the help of utilities such as make and configure), you likely remember that it was a painful process, especially if the application had several dependencies. By deciphering the various warnings and error messages, you may have been able to determine which part of the b was failing and most often that failure was due to a missing library or other dependency. You would then track down that missing library or dependency, correct it, and try again. Then, if you were lucky, the compile would complete, but often the build would fail again, complaining about another broken dependency.

APT was designed to help alleviate that problem, collate program requirements and dependencies, and resolve them. This functionality works out-of-the-box on Kali Linux, but it isn’t foolproof. It is important that you understand how Debian and Kali’s packaging system works because you will need to install packages, update software, or troubleshoot problems with packages. You will use APT in your day-to-day work with Kali Linux and in this chapter, we will introduce you to APT and show you how to install, remove, upgrade, and manage packages, and even show you how to move packages between different Linux distributions. We will also talk about graphical tools that leverage APT, show you how to validate the authenticity of packages, and delve into the concept of a rolling distribution, a technique that brings daily updates to your Kali system.

Before we dig in and show you how to use dpkg and APT to install and manage packages, it is important that we delve into some of the inner workings of APT and discuss some terminology surrounding it.

Package Source and Source Package

The word source can be ambiguous. A source package—a package containing the source code of a program—should not be confused with a package source—a repository (website, FTP server, CD/DVD-ROM, local directory, etc.) that contains packages.

APT retrieves its packages from a repository, a package storage system or simply, «package source». The /etc/apt/sources.list file lists the different repositories (or sources) that publish Debian packages.

8.1.2. Understanding the sources.list File

The sources.list file is the key configuration file for defining package sources, and it is important to understand how it is laid out and how to configure it since APT will not function without a properly defined list of package sources. Let’s discuss its syntax, take a look at the various repositories that are used by Kali Linux, and discuss mirrors and mirror redirection, then you will be ready to put APT to use.

Each active line of the /etc/apt/sources.list file (and of the /etc/apt/sources.list.d/*.list files) contains the description of a source, made of three parts separated by spaces. Commented lines begin with a # character:

Let’s take a look at the syntax of this file. The first field indicates the source type:

• deb for binary packages,
• deb-src for source packages.

The second field gives the base URL of the source: this can consist of a Kali mirror or any other package archive set up by a third party. The URL can start with file:// to indicate a local source installed in the system’s file hierarchy, with http:// to indicate a source accessible from a web server, or with ftp:// for a source available on an FTP server. The URL can also start with cdrom: for CD/DVD-ROM/Blu-ray disc-based installations, although this is less frequent since network-based installation methods are more and more common.

The cdrom entries describe the CD/DVD-ROM you have. Contrary to other entries, a CD/DVD-ROM is not always available, since it has to be inserted into the drive and usually only one disc can be read at a time. For those reasons, these sources are managed in a slightly different way and need to be added with the apt-cdrom program, usually executed with the add parameter. The latter will then request the disc to be inserted in the drive and will browse its contents looking for Packages files. It will use these files to update its database of available packages (this operation is usually done by the apt update command). After that, APT will request the disc if it needs a package stored on it.

The syntax of the last field depends on the structure of the repository. In the simplest cases, you can easily indicate a subdirectory (with a required trailing slash) of the desired source (this is often a simple “./”, which refers to the absence of a subdirectory—the packages are then directly at the specified URL). But in the most common case, the repositories will be structured like a Kali mirror, with multiple distributions each having multiple components. In those cases, name the chosen distribution, then the components (or sections) to enable. Let’s take a moment to introduce these sections.

Debian and Kali use three sections to differentiate packages according to the licenses chosen by the authors of each work. A difference between Debian and Kali is that, Debian only has main enabled by default, whereas Kali has all three enabled by default.

main contains all packages that fully comply with the Debian Free Software Guidelines.

The non-free archive is different because it contains software that does not (entirely) conform to these principles but which can nevertheless be distributed without restrictions.

contrib (contributions) is a set of open source software that cannot function without some non-free elements. These elements may include software from the non-free section or non-free files such as game ROMs, BIOS of consoles, etc. contrib also includes free software whose compilation requires proprietary elements, such as VirtualBox, which requires a non-free compiler to build some of its files.

Now, let’s take a look at the standard Kali Linux package sources, or repositories.

8.1.3. Kali Repositories

A standard sources.list file for a system running Kali Linux refers to one repository (kali-rolling) and the three previously mentioned components: main, contrib, and non-free:

Let’s take a look at the various Kali repositories.

8.1.3.1. The Kali-Rolling Repository

This is the main repository for end-users. It should always contain installable and recent packages. It is managed by a tool that merges Debian Testing and the Kali-specific packages in a way that ensures that each package’s dependencies can be satisfied within kali-rolling. In other words, barring any bug in maintainer scripts, all packages should be installable.

Since Debian Testing evolves daily, so does Kali Rolling. The Kali-specific packages are also regularly updated as we monitor the upstream releases of the most important packages.

8.1.3.2. The Kali-Dev Repository

This repository is not for public use. It is a space where Kali developers resolve dependency problems arising from the merge of the Kali-specific packages into Debian Testing.

It is also the place where updated packages land first, so if you need an update that was released recently and that has not yet reached kali-rolling, you might be able to grab it from this repository. This is not recommended for regular users.

8.1.3.3. The Kali Linux Mirrors

The sources.list extracts above refer to http.kali.org: this is a server running MirrorBrain, which will redirect your HTTP requests to an official mirror close to you. MirrorBrain monitors each mirror to ensure that they are working and up-to-date; it will always redirect you to a good mirror.

Debugging a Mirror Redirection

If you have a problem with the mirror (for instance because apt update fails), you can use curl -sI to see where you are being redirected:

If the problem persists, you can edit /etc/apt/sources.list and hardb the name of another known working mirror in place of (or before) the http.kali.org entry.

We also have a second MirrorBrain instance: where http.kali.org hosts the package repositories, cdimage.kali.org hosts the released ISO images.

If you want to request a list of official Kali Linux Mirrors, you can add .mirrorlist to any valid URL pointing to http.kali.org or cdimage.kali.org.

These lists are not exhaustive due to some MirrorBrain limitations (most notably mirrors restricted to some countries do not appear in the list unless you are in the given country). But they contain the best mirrors: they are well maintained and have large amounts of bandwidth available.

Источник