Статья Поиск пакетов для Kali Linux
В предыдущей статье мы рассмотрели управления пакетами в Kali Linux. С легкостью установки, которые обеспечивает APT, у нас есть выбор среди десятков тысяч пакетов, однако оборотной стороной является то, что у нас есть десятки тысяч пакетов. Выяснить, какие пакеты доступны и найти один, которые нам нужен, может быть сложной задачей, особенно для новичков в Linux. В этой статье мы будем рассматривать три утилиты, которые могут быть использованы для поиска через haystack и помочь вам воспользоваться обширной экосистемой с открытым исходным кодом.
Различные интерфейсы, доступные для поиска пакетов apt-cache имеет самые основные и элементарные из всех их . Однако это также интерфейс, который мы, как правило, наиболее часто используем, потому что это быстро, легко и эффективно. По умолчанию apt-cache поиск в имена пакетов, а также их описания, для данного терминала. Например зная, что во все имена метапакетов Kali Linux включена «kali-linux«, мы можем легко искать каждый из них.
Во многих случаях apt-cache возвращает слишком много результатов, потому что ищет в описании пакетов. Поиск может быть ограничен для имён пакетов с помощью варианта –names-only
Так как apt-cache имеет такой удивительный greppable выход, мы можем сохранить результаты фильтрации.
Далее можно фильтровать результаты поиска, но как только вы начинаете комбинировать вместе цепочки нескольких команд, это обычно является хорошим свидетельством того, что настало время для использования другого инструмента.
Приложение aptitude является в очень тесной связи «aka двоюродный брат» apt и apt-get, за исключением того, что она также включает в себя весьма полезный ncurses интерфейс. Он не входит в Kali по умолчанию, но она быстро может быть установлена следующим образом.
После установки и запуска aptitude без каких-либо параметров запустится ncurses интерфейс. Одна из первых вещей, которые вы заметите, это то, что вы можете быстро и легко просматривать пакеты по категориям, что значительно помогает с сортировкой среди тысячи доступных пакетов.
Для поиска пакета либо нажмите символ / или выберите «Найти» в меню «Поиск«. Когда вы вводите ваш запрос, результаты поиска пакетов будут обновляться динамически.
После того как вы нашли расположение пакета, вызывающего интерес, вы можете пометить его для установки с помощью символа + или удалить/отменить его удаление с помощью – символа.
На данный момент вы можете зафиксировать поиск для других пакетов, пометить для установки или удаления. Когда вы будете готовы к установке, нажмите клавишу g, для просмотра различных мер, которые необходимо принять.
Если вы удовлетворены предлагаемыми изменениями, нажмите g снова и aptitude завершит установку как обычно.
Если вы хотите ограничить поиск инструментов, которые собраны и упакованы командой разработчиков Kali, самый простой способ сделать это, вероятно, используя оператор поиска на Google сайте.
Надеюсь этот пост поможет вам ответить на то, доступен ли определенный инструмент в Kali (или Debian). Для более подробного обращения с управлением пакетами мы рекомендуем вам проверить сайт Kali Training.
Источник
Статья Расширенный пакет управления в Кали Linux
Огромное спасибо пользователю persivald за своевременный перевод!
Расширенный пакет управления в Kali Linux
Advanced Package Tool (APT) — это когда программы, библиотеки, документация и даже ядро установлены и настроены для работы на Kali и других Debian-подобных дистрибутивах. АРТ работает настолько хорошо, что большинство пользователей часто не замечают его присутствия, за исключением поиска некоторых программ и (надеюсь) обноволений для их системы.
Для большинства стандартных пользователей использующих АРТ таким образом (имеется ввиду установил и забыл пр.переводчика) это вполне приемлемо, но нам хочется думать, что люди использующие Kali Linux не стандартные пользователи (в хорошем смысле) поэтому мы публикуем этот пост, что бы рассказать Вам о возможностях его использования и как получить приемущества всей экосистемы доступных пакетов, сохраняя при этом стабильность Вашей Kali.
Большинство людей скажут Вам, что Вы не должны надеяться на пекетный менеджер, а напротив, компилировать всё из источника, потому что таким образом Вы будете лучше понимать систему. Частично это так, Вы многое изучите и поймёте, особенно если начнёте настройку вручную, но это довольно быстро надоедает и отнимает на мало времени, которое Вы могли бы потратить на hacking или изучение чего-нибудь нового, желательно одновременно.
В этом посту мы покажем Вам, как Вы можете безопасно добавлять дополнительные репозитории пакетов в установку Kali, как апгрейдить и откатывать обновы, и как убедиться, что всё это работает корректно. APT очень эффективен и будет оценивать доступные пакеты из всех источников в целом, когда он формулирует свои решения.
Добавление источников пакетов в Kali Linux
Если вы хотите сделать свое будущее счастливым, вы не должны напрямую редактировать /etc/apt/sources.list . Для каждого нового репозитория пакетов, который вы добавляете в свою систему, создайте новый файл с описательным именем (например, debian-unstable.list) в /etc/apt/sources.list.d/. Если оставить исходный файл sources.list нетронутым, если Kali необходимо его обновить, он не будет прерывать вас во время обновления, спрашивая, какую версию файла сохранить.В этом посте мы добавим репозиторий Kali Bleeding-Edge и нестабильные и экспериментальные репозитории Debian.
Репозиторий kali-bleeding-edge содержит ряд инструментов, которые очень популярны и меняются очень часто (даже ежедневно). Было бы непрактичным и трудоемким вручную создавать и тестировать обновленные пакеты, чтобы пакеты в этом репозитории генерировались автоматически всякий раз, когда изменяется исходный источник. С одной стороны, это означает, что обновления Ваших пакетов не старше 24х часов, но с другой стороны, эти пакеты не тестируются, поэтому вам нужно осознавать, что пакеты в этом репозитории могут время от времени ломаться.
Вы можете добавить репозиторий и обновить список доступных пакетов следующим образом.
Нестабильные и экспериментальные хранилища Debian
Kali Linux является производным от Debian Testing, у которого есть более современное программное обеспечение, чем в Debian Stable. Для еще более позднего программного обеспечения существует дистрибутив Debian Unstable, который является rolling версией Debian, содержащей самые последние пакеты. Когда вы сталкиваетесь с ошибкой в пакете Debian, в репозитории Debian Unstable уже может лежать исправленая версия, поэтому рекомендуется добавить ее в вашу систему Kali. Как и в случае с kali-bleeding-edge, пакеты в Unstable могут время от времени ломаться.
Debian Experimental — еще один репозиторий, содержащий пакеты, которые находятся в разработке. Пакеты в этом репозитории всегда обновляются, но при этом могут быть очень глючными, даже хуже, чем в kali-bleeding-edge или Debian Unstable. APT будет устанавливать пакеты только из этого репозитория, если вы явно запросите их, и вы всегда можете всегда откатиться, если что-то перестанет работать.
Определение приоритетов пакетов
Чтобы определить, какие пакеты будут установлены, APT умеет назначать приоритеты для всех источников пакетов, отдавая предпочтение наивысшему приоритету. Пакет с приоритетом 0 никогда не будет установлен, а пакет с приоритетом более 1000 будет всегда установлен, даже если это откат пакета на старую версию.
Это прекрасно для APT, но как пользователь сможет увидеть, какой приоритет назаначен конкретному пакету? Введите малоизвестную команду «apt-cache» и ее опцию «policy», которая покажет все ваши настроенные репозитории и их назначенные приоритеты.
Настройка распределения по умолчанию
Теперь, когда вы добавили допольнительные репозитории в вашу систему, вы захотите начать изучение и установку новых пакетов, но прежде чем вы это сделаете, неплохо сообщить APT, что ваш дистрибутив по умолчанию, который для пользователей Kali Linux — это «kali -rolling». Таким образом, ваша система не будет обновляться из какого-либо другого дистрибутива без вашего согласия. Настройте свой дистрибутив по умолчанию, добавив «APT :: Default-Release» kali-roll «;» в /etc/apt/apt.conf.d/local.
Если вы назначили свой дистрибутив по умолчанию, каждый раз, когда вы запускаете «apt full-upgrade», он будет применять обновление для kali-rolling, что поможет поддерживать стабильность вашей системы.
Запрос сокращения обновления
Если вы используетесь каким-либо Debian-подобным дистрибутивом достаточно давно, то при запуске «apt upgrade» вы сталкиваетесь с запросом о файле конфигурации и хотите ли вы сохранить локальную версию, использовать новую версию или сравнить ее. Чаще всего вы принимаете дефолт, лишь отвлекаясь на эти запросы.
Можно избежать этих запросов, обновив файл /etc/apt/apt.conf.d/local с помощью параметров «DPkg :: options» («-force-confdef»; «-force-confold»; >’ как показано ниже. Эта строка сообщает APT действовать самостоятельно: если файлы не изменились (-force-confdef), а если файлы разные, то можно сохранить существующую версию (-force-confold).
Закрепление версии пакетов
Иногда вы обнаруживаете одно из приложений, которое нуждается в определенной версии конкретного пакета и не будет работать с каким-либо другим. В некоторых случаях обновление одного пакета может негативно сказаться на других инструментах. Это произошло недавно с обновлением пакета devscripts, что мешало нам создавать пакеты Kali.
К счастью, APT позволяет привязать пакет к определенной версии, установив приоритет 1001 в / etc / apt / preferences. Например, чтобы сообщить APT, чтобы пакет devscripts содержал версию 2.16.x, вы должны добавить следующее:
В этой статье мы лишь поверхностно коснулись того, как вы можете расширить APT далеко за пределы стандартной экосистемы Kali или Debian. Алгоритмы АРТ очень эффективны, и проблемы в них встречаются редко, поэтому вам не нужно бояться пробовать другие репозитории. Чтобы узнать больше об APT и о том, как настроить его по своему желанию, мы рекомендуем обратиться к Kali Linux Revealed и The Debian Administrator’s Handbook, в которых содержится множество информации, советов и трюков.
Источник
Getting involved in the Kali ecosystem
Kali Linux has a large number of tools that it maintains and adds on a regular basis. However, we can’t always consider every request for a package to be added because of the large number of requests. Because of this, we have developed requirements that we have users follow in order to increase the chances that we see them, and then are able to properly consider them. If you have visited the bug tracker you may have noticed the requirements posted on certain package requests. If you haven’t, no worries, because they are as follows:
You may be asking at this point ‘How does this relate to me getting involved?’. Well that’s simple: users can now do most of the work on their own to get the tool added thanks to our move to GitLab. Keep in mind that we still will not be adding all tools that are requested; perhaps there is a different tool that does the same thing but has been around longer, or maybe the tool is too new and needs time to really get more user’s opinion on. There are a few things that those who want to get involved need to do first, which is what we are going to walk you through now.
For those of you who want to get involved and maintain your package, you’re going to need to create a merge request. There are two things to know during this. The first is how to create the initial package and the other is how to continue supporting it. For easier understanding, let’s take a visual look at this.
Creating the initial folder
Before we start the “packaging” we need to get the folder prepared properly. Assuming the tool you want to package is already prepared and you are the owner, it is recommended to create a separate branch and add it directly in the “debian” directory. After this is done, skip to “Creating the Debian files” and follow along from there.
Otherwise, you need to pull the release if they have one. If they do have a release, skip to that header. If they don’t have a release, clone the repo and do the following command:
Be sure to change both package and date to the appropriate names.
We create an empty git repo and then clone it, then we can import the tool. Be sure to create a new empty repo of your own for your own package for this step.
Working with a release
To get the release, we follow a similar process as to when there is no release. We first get the latest release tar.gz link and output the file to the proper Debian format.
Creating the Debian files
First we need to generate the base Debian files and remove some of the ones that won’t be needed. When prompted we select single for the package type, and assuming everything else is correct, the default values for the rest.
Next we will need to edit some of the files with the proper information.
There are a number of things to take note of here. Section, priority, maintainer, uploaders, homepage, depends, and description are all changed. Going through them:
- ‘section’ will be what type of tool it is. Put in your best guess as to what it may be in the general area (web, net, etc) and we will change it if need be
- Priority can be set to optional
- Maintainer should always be “Kali Developers devel@kali.org” and Uploaders should be your name (it can be account name) and the email associated with the account
- The homepage is where the tool is originally from. Depends is whatever needs to be installed to make the tool work, which, in this case php is needed
- Vcs-* should be set to your repo that you are pushing the package to.
- Description is the combination of the short description and an extended one that explains what the package contains
Be sure to set kali-dev rather than unstable before urgency, otherwise there will be issues later from sbuild. You can remove everything after “Initial release”. We also use a Debian revision of “-0kali1” instead of the default “-1” to avoid conflicts with a version that would be used by an upstream Debian package.
There will be a lot of clutter when you first open copyright, most can be deleted but be sure to read what you are removing as some information may be important. The copyright and license for Files: * will be whatever the original package uses. In this case, the original package used Apache License 2.0, and as it has the full license already in Debain it can be linked to as above. A good command to know of is licensecheck -r . —copyright which will give a rough idea on if there are any licenses that were missed.
This file can look a bit intimidating, but what actually needs to be changed is very easy as demonstrated:
This file will watch for any changes in the released version number of the upstream, which will allow updating the package on time later easier. There are more examples available on the Debian wiki.
Final touches
If we built the package now, it would not be installed. To fix this, let’s create an .install file and a helper script. The reason we are creating these two files is that they both will work the majority of the time. In some cases, the different ways, like using a symlink, may not work and changes will have to be made. As we can’t account for every scenario now, we will go with what works the majority of the time.
Some of you may have caught something odd and are wondering what’s up with the formatting of the .install file. With the way that the package builder interprets things, a / at the beginning of “usr/” will break things, likewise no slash at the end will as well. We include all the files that will be installed in the “.install” file. In the helper-script, we go to that directory and launch the file.
Now that all that is done, we can push everything to git and try it out!
This may take a little bit, and in the end a few things can occur. If lintian says “Failed” and there are errors, we recommend googling them and if no solution can be found then submit a post to the forums where we can assist. If lintian does not fail, then you can find your package in /home/$USER/kali/build-area/ . Be sure to test it out by using dpkg to install the package and run it.
Menu icon
If a .desktop file is needed to be created for a menu icon, then this is best done by submitting a merge request to the kali-menu package on GitLab. Fork the package, clone it, add in the file you’d like, and then you can submit a merge request with your changes. Below is an example of how the .desktop file should be done. Be sure to change “Categories” to whichever most closely fits the tool, and it is possible to include more than one.
Submitting to the tracker
Just one last thing to do; submit it to us! To do this, lets head over to Kali’s issue tracker. We are going to want to submit a new issue with the category “New Tool Requests”. For the title we will call it “phpggc: a library of unserialize() payloads along with a tool to generate them” and for the description we will include that list from earlier.
Once done, simply submit the issue and we will review it.
What happens after we accept
When we accept the package into Kali, we duplicate the git repository into our kalilinux/packages GitLab group (through forking and deleting the relationship). Because of this, future changes made will need to be submitted as merge requests. In order to do this, users will have to fork our git repository into their account.
Updated on: 2021-Sep-27
Author: gamb1t
Источник
