- Kali linux rolling repositories
- Default Network Repository Value
- Switching Branches/Regular Repositories
- Sources.list Format
- Default Offline Install Values
- Non-Kali Repositories
- Mirrors
- Source Repositories
- Kali linux rolling repositories
- Kali Branches
- Development
- Branches Used to Assist With Other Branches
- Mapping
- Debian’s Relation
- The kali-rolling Repository
- The kali-dev Repository
- Статья Проверка и восстановление репозиториев в Kali Linux из командной строки
- Pirnazar
- The Codeby
Kali linux rolling repositories
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
Источник
Kali linux rolling repositories
A branch is an alternative version of some software, in this case of the Kali OS. Kali Linux has multiple branches which allows for users to decide how up-to-date their packages will be. Kali Linux is similar to Debian in many regards, one of which is the use of branches.
You may have multiple branches enabled at once. However, switching branches may introduce problems, as packages may be at different versions, and unavailable or unstable in certain cases.
Please see the network sources page for how to switch branches. For an example of how to use multiple branches, please see our NVIDIA GPU Drivers guide.
Kali Branches
First are the main branches, which are the most frequently used, and the most stable. These are often seen as “safe”.
- kali-rolling is the main default branch that most should be using. It is being continuously updated, as it pulls from kali-dev after ensuring questionable packages are stable and combining them with packages from kali-rolling-only . From time to time, a package bug may slip into here, due to bugs in debian-testing .
- kali-last-snapshot is a branch of Kali that can be used if users want a more standard feeling of software control. For every new release, we freeze the code and merge kali-rolling into kali-last-snapshot , at which point users will get all of the updates between versioned releases (i.e. 2020.3 -> 2020.4). This often is more stable, as packages are not updated (until the next release as it’s a “Point Release”) and go thought our release testing. This is the “safest” option.
Next are those that you will likely not need except in very special cases:
- kali-experimental is a staging area for work-in-progress packages.
- kali-bleeding-edge contains packages that are automatically updated from the upstream git repositories. This branch has the potential to be very unstable.
Development
- kali-dev is the development version of Kali Linux. It is created by combining three other branches: kali-dev-only , kali-debian-picks and debian-testing . Its mainly used for merging Debian’s updates with the changes maintained by Kali Linux.
- kali-dev-only is the development distribution with Kali-specific packages. This branch is auto-merged into kali-dev .
- kali-rolling-only is a repository for packages that need to quickly reach kali-rolling .
Branches Used to Assist With Other Branches
- kali-debian-picks contains packages cherry-picked from debian-experimental and debian-unstable . It is auto-merged into kali-dev .
- debian-testing is a mirror of Debian’s testing distribution. This is used to build kali-dev .
- debian-experimental and debian-unstable are partial mirrors for specific packages that we want to cherry-pick.
Mapping
Below is a diagram showing the relationship between the branches.
Debian’s Relation
Debian has three main options:
Stable is the “safe” Debian branch. Around every two months, it is updated with a “Point Release”, which is often just security updates. Packages don’t generally get a version upgrade during this time, due to potential incompatibility and thus instability. This is the Debian equivalent of kali-last-snapshot.
Testing is the closest thing there is to a Debian “rolling” distribution, where “rolling” means that as soon as a package update is available, it’s pushed out. Kali has used this branch as a starter for kali-rolling since January 2016.
Unstable is just after Debian’s package development happens. The packages have been created, but not fully tested. Kali doesn’t have an equivalent, as it is a rolling distribution.
For more information about how Kali relates to Debian, please see our policy page on the matter.
The kali-rolling Repository
Contrary to kali-dev, kali-rolling is expected to be of better quality because it’s managed by a tool that ensures installability of all the package it contains. That tool picks updated packages from kali-dev and copies them to kali-rolling only when they have been verified to be installable. Note however that those checks do not include any functional testing. It might still contain broken software due to other problems that are not covered by the package dependencies. Kali Rolling is the primary repository that most users should be using. They can also report any issue they have with Kali specific packages on bugs.kali.org. Make sure to select the “kali-dev” version in “Product version”.
Kali Rolling users are expected to have the following entries in their /etc/apt/sources.list:
The kali-dev Repository
WARNING: While kali-dev is publicly accessible to everybody on all Kali mirrors, this distribution should not be used by end-users as it will regularly break.
This repository is actually Debian’s Testing distribution with all the kali-specific packages (available in the kali-dev-only repository) force-injected. Kali packages take precedence over the Debian packages. Sometimes when Testing changes, some Kali packages must be updated and this will not happen immediately. During this time, kali-dev is likely to be broken. This repository is where Kali developers push updated packages and is the basis used to create kali-rolling.
Источник
Статья Проверка и восстановление репозиториев в Kali Linux из командной строки
Вроде что-то и есть, но вроде и что-то не так. Чтобы было быстро и просто проверить состояние репозиториев, я написал вот такую длинную команду:
Решить эту проблему можно одной единственной командой:
Внимание, эта команда полностью затирает файл sources.list (в котором хранятся источники приложений). Т.е. если вы вручную туда что-то добавляли, то команда это сотрёт. Также удаляются комментарии, пустые строки и пр. – результатом команды является то, что в этот файл записываются две строчки — официальные источники приложений Kali.
Опять проверяю репозитории:
Можно опять проверить содержимое файла источников:
Отлично — всё есть и ничего лишнего.
После обновления репозитория, обязательно выполняем:
Pirnazar
The Codeby
ООО Кодебай
Подскажите, пожалуйста, что делать в данном случае?
WEBWARE TEAM
30.07.2015 в 09:29
Попробуйте так
О полученных результатах напишите, пожалуйста.
EZZE
22.12.2015 в 15:48
Вместо Для Kali 1.x добавляем репозитории для 2.х
У меня так сработало на версии Kali 1.1.0a
EZZE
22.12.2015 в 21:10
Наврал. При update && upgrade начал херню какую то гнать.
Нашел вот этот репозитории.
Работают.Испитания проводились на Kali 1.1.0a
SEEBAR
31.07.2015 в 13:55
К сожалению, опять всплыло это окошко и обновиться не получилось. Хоть жди версии 2.0
РАДИК
16.09.2015 в 05:46
Спасибо, автор красавчик. всё чотко и без понтов )))
KIDLUCK
04.10.2015 в 20:29
А обратно как вернуть, чтобы редактировать можно было?
ALEXEY
08.11.2015 в 20:03
Спасибо. Всё получилось.
АНДРЕЙ
08.03.2016 в 00:35
огромное спасибо, никакими методами не получалось, только Вашим все вышло с первого раза. Еще раз спасибо за подробную инструкцию
PWCPLE
14.05.2016 в 04:30
На сайте Kali рекомендуют добавить еще этот репозиторий:
Он появился начиная с 2016.1 версии. Они называют его самым лучшим.
А по сути, нельзя добавлять только kali dev.
PWCPLE
14.05.2016 в 04:31
Еще хотел добавить, что без него нельзя, например, установить aptitude.
OLEGON
20.05.2016 в 00:14
Весь день промучился сэтими репами, безрезультатно!
Но после прочтения этой статьи, все получилось с первого раза!
Огромное спасибо Автору! Доволен как слон!
ЕВГЕНИЙ
01.06.2016 в 10:51
У меня вылезла вот такая ошибка
У меня kali linux 2.0.На ubuntu наблюдал тоже самое.Ссылки не работают
Или не стоит волноватся раз они просто выключили несколько серверов?
OLEDVANT
07.01.2017 в 13:16
Всё сделал,как написано!Но вот что вылезло в конце!
Что делать?Как быть?
ULTRON
06.02.2017 в 13:49
Никак не могу настроить apt. Ругается, что пытаюсь загрузить по протоколу https и для него не установлен драйвер в то время, как в листе чётко прописал, что по http. Как это так странно получается?
TARIK
16.05.2017 в 11:46
leafpad
TARIK
16.05.2017 в 11:50
WIPE MEMORY
16.05.2017 в 23:30
Спасибо за инструкцию, помогло
MCSTL
24.08.2017 в 10:22
эта статья сподвигла меня написать авто-обновление репозитория, так что я начал осваивать bash, но написал я через переменные что дает возможность просто поменять адреса (dist 1-2) путь (way) и это подойдет к другой системе (это объясняет наличие sudo), я например заинтересовался backbox она легче и не подтормаживает на виртуальной машиyе и кажется с tor там все проще.
заливать ни куда не стал, можно просто создать файл в leafpad сохранить как угодно с расширением .sh например “123.sh” куда ни будь в Documents, а потом просто перейти в директорию cd
/Documents/; и запустить bash 123.sh, думаю при постоянных установках kali это достаточно удобно. вот код:
Источник