Shared libraries что это за программа

Выполнение разделяемых библиотек в Linux

Известно, что при запуске практически любой unix-программы, передав ей в качестве ключа —help, —usage или —version, мы получим некоторую информацию о данной программе: опции командной строки, комментарии, email-адреса разработчиков, версию программы и так далее. Эта информация дает возможность сразу пользоваться программой, не залезая в man’ы и не погружаясь в чтение документации. Даже для того, чтобы понять смысл программы wc, достаточно запустить ее с ключом —help:

chumka bin # wc —help
Usage: wc [OPTION]. [FILE].
Print newline, word, and byte counts for each FILE, and a total line if
more than one FILE is specified. With no FILE, or when FILE is -,
read standard input.
-c, —bytes print the byte counts
-m, —chars print the character counts
-l, —lines print the newline counts
-L, —max-line-length print the length of the longest line
-w, —words print the word counts

You’ll Wish You Knew About Shared Libraries Earlier

—help display this help and exit
—version output version information and exit

Однако такой возможности практически не существует для разделяемых библиотек. Им невозможно передать аргументы командной строки, более того — их даже нельзя запустить. В ответ на попытку запуска мы получим банальный Segmentation fault. Библиотека-исключение — это стандартная, хорошо известная libc. Параметры командной строки она не принимает, но запускаться может, выдавая тем самым информацию о себе самой.

В данной статье мы поговорим о создании библиотек с возможностью их запуска и передачи им аргументов из командной строки. В ответ библиотека выдаст нам информацию об авторе и документацию своих функций. В качестве примера создадим небольшую библиотеку myexec:

int my_main(int argc,char *argv[]) printf(«Main started. Argc: %dn»,argc);
for (;*argv;*argv++) printf(» %sn»,*argv);
exit(0);
>
int f1(void) < printf(«function %sn»,__FUNCTION__); >
int f2(void)

Функции f1() и f2() являются функциями библиотеки, из-за которых она собственно и пишется. Нас они не интересуют, поэтому они будут просто выводить свое имя сразу после вызова. Именно эти функции мы будем документировать. Функция my_main() будет точкой входа в библиотеку. Она показывает все входные аргументы, переданные из командной строки.

Вызов exit() в конце обязателен, так как после выполнения функции my_main() управление никуда не возвращается, как в случае обычных выполняемых файлов. Поэтому нам нужно самостоятельно завершить выполнение.

Собираем, запускаем и видим то, что ожидали:

chumka ~ # gcc -fPIC -shared my.c -o libmyexec.so
chumka ~ # ./libmyexec.so
Segmentation fault

Почему же ошибка?

При запуске выполняемого файла в Unix, ядро ОС сначала загружает в память специальный загрузчик, расположенный в заголовке ELF-файла, а именно в строке INTERP. Эта строку заголовка формирует линкер при компоновке файла, основываясь на секции .interp объектного файла. Далее ядро передает управление этому загрузчику, который, в свою очередь, загружает образ файла в память и передает ему управление. Просмотрим ELF-заголовок нашей только что собранной библиотеки и ELF-заголовок обычного выполняемого файла, для примера возьмем уже знакомый wc (часть вывода обрезана):

Shared libraries in OneDrive

chumka ~ # objdump -p `which wc`
/bin/wc: file format elf32-i386

Program Header:
PHDR off 0x00000034 vaddr 0x08048034 paddr 0x08048034 align 2**2
filesz 0x00000120 memsz 0x00000120 flags r-x
INTERP off 0x00000154 vaddr 0x08048154 paddr 0x08048154 align 2**0
filesz 0x00000013 memsz 0x00000013 flags r—
LOAD off 0x00000000 vaddr 0x08048000 paddr 0x08048000 align 2**12
filesz 0x00004108 memsz 0x00004108 flags r-x
LOAD off 0x00004108 vaddr 0x0804d108 paddr 0x0804d108 align 2**12
filesz 0x000001ac memsz 0x00000344 flags rw-
DYNAMIC off 0x0000411c vaddr 0x0804d11c paddr 0x0804d11c align 2**2
filesz 0x000000c8 memsz 0x000000c8 flags rw-
NOTE off 0x00000168 vaddr 0x08048168 paddr 0x08048168 align 2**2
filesz 0x00000020 memsz 0x00000020 flags r—
EH_FRAME off 0x00004090 vaddr 0x0804c090 paddr 0x0804c090 align 2**2
filesz 0x0000001c memsz 0x0000001c flags r—
STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2
filesz 0x00000000 memsz 0x00000000 flags rw-
PAX_FLAGS off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2
filesz 0x00000000 memsz 0x00000000 flags — 2800
.
chumka ~ # objdump -p ./libmyexec.so
/home/lamer/lib/libmyexec.so: file format elf32-i386

Program Header:
LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**12
filesz 0x00000690 memsz 0x00000690 flags r-x
LOAD off 0x00000690 vaddr 0x00001690 paddr 0x00001690 align 2**12
filesz 0x00000104 memsz 0x00000108 flags rw-
DYNAMIC off 0x000006a4 vaddr 0x000016a4 paddr 0x000016a4 align 2**2
filesz 0x000000c0 memsz 0x000000c0 flags rw-
STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2
filesz 0x00000000 memsz 0x00000000 flags rw-
PAX_FLAGS off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2
filesz 0x00000000 memsz 0x00000000 flags — 2800
.

Видно, что строка INTERP в заголовке нашей библиотеки отсутствует, тем самым ядро не может найти загрузчик в библиотеке и выдает ошибку. Наша задача — создать эту строку, но мы поручим эту задачу линкеру ld. А сами тем временем просто добавим секцию .interp в объектный файл. Сделать это можно по-разному, например, просто добавить в начало исходного файла имя загрузчика с указанием компилятору поместить эту строку в секцию .interp:

const char interp[] __attribute__((section(«.interp»))) = «/lib/ld-linux.so.2»;

и собрать заново:

chumka ~ # gcc -fPIC -shared -Wl,-e,my_main my.c -o libexec.so

Файл /lib/ld-linux.so.2 является загрузчиком для ОС Linux.

Другой способ не требует вмешательства в исходный код библиотеки. Требуемая секция добавляется в объектный файл с помощью утилиты objcopy:

chumka ~ # echo -ne «/lib/ld-linux.so.2» > ./tmpfile
chumka ~ # gcc -c -fPIC my.c
chumka ~ # objcopy —add-section .interp=./tmpfile —set-section-flags .interp=contents,alloc,load,readonly,data my.o
chumka ~ # gcc -shared -Wl,-e,my_main my.o -o libmyexec.so

Параметр -Wl,-e,my_main заставляет gcc указать линкеру, что точкой входа будет являться функция my_main().

Проверим, что линкер создал строку INTERP и секцию .interp (часть вывода вырезана):

chumka lib # objdump -s -j .interp -p ./libmyexec.so
./libmyexec.so: file format elf32-i386

Program Header:
PHDR off 0x00000034 vaddr 0x00000034 paddr 0x00000034 align 2**2
filesz 0x000000e0 memsz 0x000000e0 flags r-x
INTERP off 0x000006e4 vaddr 0x000006e4 paddr 0x000006e4 align 2**0
filesz 0x00000013 memsz 0x00000013 flags r—
LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**12
filesz 0x000006fc memsz 0x000006fc flags r-x
LOAD off 0x000006fc vaddr 0x000016fc paddr 0x000016fc align 2**12
filesz 0x00000104 memsz 0x00000108 flags rw-
DYNAMIC off 0x00000710 vaddr 0x00001710 paddr 0x00001710 align 2**2
filesz 0x000000c0 memsz 0x000000c0 flags rw-
STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2
filesz 0x00000000 memsz 0x00000000 flags rw-
PAX_FLAGS off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2
filesz 0x00000000 memsz 0x00000000 flags — 2800
. Contents of section .interp:
06e4 2f6c6962 2f6c642d 6c696e75 782e736f /lib/ld-linux.so
06f4 2e3200 .2.

Строка в секции .interp обязательно должна заканчиваться нулевым символом, иначе ядро не сможет правильно определить путь к загрузчику. Теперь проверим запуск библиотеки:

chumka ~ # ./libmyexec.so 4 5
Main started. Argc: -1078608707
Segmentation fault

Функция my_main() запустилась, но параметры передались не в том порядке_ в котором мы ожидали. За передачу параметров от ядра к функции main() отвечает специальный код компилятора, запакованный в объектный файл сrt1.o. При передаче управления от ядра к выполняемому файлу в стеке процесса содержатся:

1. Число аргументов командной строки
2. Массив указателей на аргументы командной строки

Однако функция my_main() справедливо полагает, что первое значение в стеке есть адрес возврата вызвавшей ее функции. Ядро, как мы знаем, этот адрес не кладет в стек. Таким образом, мы теряем аргумент argc, остальные аргументы можно достать средствами языка C. Решение, кажется, лежит на поверхности. Достаточно «обернуть» вызов функции my_main() в какую-нибудь другую функцию, например:

Тогда вызывающая функция pre() положит в стек свой адрес возврата, который нам вообще-то не нужен, и my_main() благополучно доберется до нужных значений в стеке. Однако, просмотрев код с помощью objdump -d -j .text ./libmyexec.so, увидим, что вызов pre() засоряет стек трижды, планируя вернуть все на свои места после своего завершения, то есть уже после вызова my_main():

00000660 :
660: 55 push %ebp 661: 89 e5 mov %esp,%ebp
663: 53 push %ebx 664: 83 ec 04 sub $0x4,%esp 667: e8 00 00 00 00 call 66c
66c: 5b pop %ebx
66d: 81 c3 dc 11 00 00 add $0x11dc,%ebx
673: e8 cc fe ff ff call 544
678: 83 c4 04 add $0x4,%esp 67b: 5b pop %ebx 67c: c9 leave 67d: c3 ret

В п. 1,2,3 стек засоряется, а в п. 4,5,6 вычищается. Как видно, п. 4,5,6 происходят после вызова my_main(), поэтому нам придется очистить стек самостоятельно до вызова нашей входной функции. По адресу 667-66с делается операция получения текущего адреса выполнения программы в регистр ebp: инструкция call положит адрес возврата в стек, а инструкция pop тут же его оттуда вытащит, поэтому эта часть на положение стека не влияет. Регистр ebp необходим для доступа к таблице PLT нашей библиотеки.

Также нам нужно создать указатель на массив указателей на аргументы командной строки, так как наша my_main(), как и обычная main(), принимает его в качестве второго аргумента. Итак, нам нужно очистить три двойных слова из стека и создать указатель. Вариантов сделать это предостаточно, вот один из вариантов функции pre():

В п.1 очищаем ebp, далее очищаем стек на четыре двойных слова (вместо трех), обращаемся к памяти за стеком и достаем argc. В п. 4 создаем нужный указатель и в п.5 складываем готовые аргументы в стек для передачи my_main(). И наконец, в п.6 вызываем ее. Вставляем этот код в начало библиотеки, собираем c новой точкой входа pre и запускаем:

chumka ~ # ./libmyexec.so arg1 arg2 arg3
Main started. Argc: 4
./libmyexec.so
arg1
arg2
arg3

Функция вывела все 4 аргумента (первый — это имя самой программы). Ну а дальше все в руках программиста. Используя стандартный getopt(), параметры перебираются и обрабатываются в нужном русле. Не забудем запустить какую-нибудь тестовую программку test для проверки работы самой библиотеки:

что даст нам ожидаемый вывод:

chumka ~ # ./test
function f1
function f2/

Источник: xakep.ru

Русские Блоги

Linux | Статические и разделяемые библиотеки и их производство

Справочник статей

• 1. Библиотека

• Что такое библиотека?

• Что такое статическая библиотека?
• Создание и использование статических библиотек

• Что такое общая библиотека?
• Создание и использование общих библиотек

1. Библиотека

Что такое библиотека?

Библиотека — это набор предварительно скомпилированных методов (функций). ** По сути, библиотека — это двоичная форма исполняемого кода, которая может быть загружена в память для выполнения операционной системой. ** Поскольку Windows и Linux существенно различаются, двоичные файлы двух библиотек несовместимы. Разделенный на две формы: статическая библиотека (.a.lib) и общая библиотека, также известная как динамическая библиотека (.so.dll).

• Стандартный путь к файлам репозитория Linux: / lib, / usr / lib
• Стандартный путь для хранения файлов библиотеки: / usr / include
• Сохранение команды: / usr / bin, / bin

Во-вторых, статическая библиотека

Что такое статическая библиотека?

Под статической библиотекой понимается упаковка всех связанных объектных файлов в один файл, то есть файл статической библиотеки, расширение по умолчанию:.a , Связанная статическая библиотекаСкопируйте вызываемый код из библиотеки в вызывающий модуль. Статическая библиотека занимает много места, и после изменения кода в библиотеке ее необходимо повторно связать, Код, который использует статические библиотеки, не должен зависеть от библиотеки во время выполнения, иВысокая эффективность。
Соглашение об именах статических библиотек должно быть * «lib [your_library_name] .a» *:lib — префикс, середина — имя статической библиотеки, а расширение — .a。

Создание и использование статических библиотек

#include «my.h» int add(int x,int y) return x+y; >
#include «my.h» int max(int x ,int y) return x>y ? x:y; >
int max(int x,int y); int add(int x,int y);
#include #include #include //#include int g = 66; int main() int a = 22; printf(«add=%d,max=%dn»,add(a,g),max(a,g)); exit(0); >

Затем add.c max.c превращается в статическую библиотеку libMyfoo.a, а методы add и max напрямую используются в main.c.

• Все файлы .c скомпилированы в файлы .o.eg：gcc -c add.c gcc -c max.c
• Упакуйте и сделайте библиотеку, ar crv libxx.a * .oeg：ar crv libmyfoo.a add.o max.o
• Затем непосредственно скомпилируйте программу main.c.Так как эта статическая библиотека не помещена в стандартный путь к файлу библиотеки, добавьте ** — L **, чтобы указать файл библиотеки.eg：gcc -o main main.c -L. -lmyfoo
• Чтобы решить вышеупомянутые проблемы,cp libmyfoo.a /usr/lib Записать самописную статическую библиотеку libmyfoo из c в стандартную библиотеку / usr / lib черезcp my.h /usr/inlcude Поместите файл заголовка в стандартную библиотеку заголовочных файлов / usr / include,Вам не нужно добавлять -L для завершения компиляции
• Статическая библиотека должна быть указана для добавления -lXXX при компиляции (xxx — это содержимое в libxxx)

В-третьих, общая библиотека

Что такое общая библиотека?

Самая большая разница между разделяемыми библиотеками и статическими библиотеками заключается в том, чтоПри связывании разделяемой библиотеки не нужно копировать код, вызываемый в библиотеке, в вызывающий модуль.Вместо этого в вызывающий модуль встроен только относительный адрес вызываемого кода в общей библиотеке. ** Если код в общей библиотеке используется несколькими процессами одновременно, во всем пространстве памяти требуется только одна копия экземпляра общей библиотеки, что означает совместное использование. *Совместно используемая библиотека занимает мало места, даже если код в библиотеке изменен, пока интерфейс остается неизменным, повторная связь не требуется.Код, использующий разделяемые библиотеки, должен полагаться на библиотеку во время выполнения, а эффективность выполнения немного ниже, Расширение по умолчанию для разделяемой библиотеки:.so
Соглашение об именовании разделяемой библиотеки, должно быть»lib [your_library_name] .so» *: lib — префикс, середина — имя разделяемой библиотеки, а расширение — .so

Создание и использование общих библиотек

• Все файлы .c скомпилированы в файлы .o
• Создать общую библиотеку gcc -shared -fPIC -olibXXX.so *.o
• Через cplibxxx.so / usr / lib поместит сгенерированный файл общей библиотеки libxxx.so в системный путь к стандартной библиотеке
• gcc -o main main.c -L указывает файл библиотеки -l указывает имя библиотеки
  Библиотека C ищется по умолчанию, а остальные не ищутся. Если в программе используются другие библиотеки, вам необходимо указать имя библиотеки
• Проверьте, какие разделяемые библиотеки используются исполняемой программой: имя исполняемой программы ldd
• Переменная среды LD_LIBRARY_PATH: Путь к системе для поиска стандартных библиотечных файлов. Путь поиска может быть указан в терминале. Он станет недействительным после закрытия терминала и временного изменения
  LD_LIBRARY_PATH =. (. — текущая позиция, в середине не должно быть пробелов, в это время LD_LIBRARY_PATH — локальная переменная, которую можно просмотреть с помощью echo $ LD_LIBRARY_PATH)
  экспорт LD_LIBRARY_PATH (установите LD_LIBRARY_PATH в качестве переменной среды)

В-четвертых, разница между статическими библиотеками и общими библиотеками

Давайте удалим вышеупомянутую статическую библиотеку и разделяемую библиотеку и посмотрим результаты.

Как видно из рисунка ниже, после удаления статической библиотеки программа все еще может работать.

Как видно из рисунка ниже, после удаления общей библиотеки программа не может быть запущена.

Мы заключаем следующее:

Статическая библиотека при создании исполняемой программы,Метод статической библиотеки включен в исполняемую программуТо есть удалить статическую библиотеку, но поскольку метод статической библиотеки был включен в исполняемую программу, программа все еще является исполняемой и больше не зависит от внешней статической библиотеки.

Общая библиотекаСпособ динамической загрузки библиотеки только при запуске программыЕсли общая библиотека удалена, общая библиотека не может быть найдена, когда программа динамически загружается во время работы программы, и программа не может быть выполнена.

Скорость работы статической библиотеки высока, но объем программы относительно велик, и обновить версию нелегко. Если она обновлена, программу необходимо перекомпилировать;
Так как совместно используемая библиотека должна динамически загружать файл библиотеки, скорость работы низкая, но программа небольшого размера, что удобно для обновления версии, и программу не нужно перекомпилировать

Источник: russianblogs.com

Разработка и тестирование Jenkins Shared Library

В компаниях с большим количеством проектов часто возникает ситуация, когда при разработке пайплайнов мы начинаем повторять себя, добавляя в разные сервисы одинаковые конструкции. Это противоречит основному принципу программирования DRY (Don’t Repeat Yourself), а ещё усложняет внесение изменений в код. Справиться с описанными проблемами помогает Jenkins Shared Library.

Мы пообщались с Кириллом Борисовым, Infrastructure Engineer технологического центра Deutsche Bank, и узнали, какие задачи решает Jenkins Shared Library и что её внедрение даёт компании. А ещё рассмотрели кейс разработки и тестирования с примерами кода.

Что такое Jenkins Shared Library

Jenkins Shared Library — это библиотека для многократного использования кода, которая позволяет описать методы один раз и затем применять их во всех пайплайнах. Она решает проблемы дублирования кода и унификации. Благодаря ней нам не нужно держать в каждом пайплайне огромное количество кода и постоянно повторять его. Мы можем написать код в одном месте, а потом инклюдить и вызывать его в рамках самого пайплайна.

Как это работает? Первым делом во всех пайплайнах мы выделяем общие части, которые можем объединить. Предположим, мы заметили, что везде используем нотификацию в Telegram, и везде она реализована по-разному. Мы создаем библиотеку, в ней делаем модуль нотификации и внедряем его во все проекты.

Затем смотрим, что ещё можем унифицировать. Например, обращение к внутренней системе, которое тоже везде реализовано по-разному. Мы заносим этот кусочек кода в библиотеку и далее распространяем на каждый микросервис. Так, выделяя общие части в каждом пайплайне, мы постепенно обогащаем нашу библиотеку и имплементируем её в наш пайплайн.

Польза Jenkins Shared Library для компании

Jenkins Shared Library уменьшает количество кода в пайплайне и повышает его читаемость. Для бизнеса это не столь важно, его больше заботит скорость доставки новых версий продукта до конечных пользователей. А здесь многое зависит от скорости разработки. Если каждая команда компании перестанет придумывать своё и начнёт использовать наработки других, вероятнее всего, разработка пайплайнов пойдёт быстрее. Соответственно, процесс доставки обновлений тоже ускорится.

С точки зрения самой команды, Jenkins Shared Library одновременно и усложняет, и упрощает работу. Например, проводить онбординг оказывается проще — вы показываете всё в одном месте. В то же время командам становится сложнее взаимодействовать. Сложность заключается в необходимости постоянной коммуникации.

Когда решаем изменить что-то у себя в библиотеке, мы сначала должны синхронизироваться с другой командой, чтобы убедиться, что у неё ничего не сломается. Но обычно это решается регулярными синками, ревью кода и пул-реквестами.

Как команда понимает, что пора внедрять Jenkins Shared Library

На прошлом проекте у нас было 20 микросервисов, очень похожих между собой. Они были написаны по одному скелету на Java, а ещё в каждом из них лежал Jenkins file, где был описан пайплайн сборки проектов. Всякий раз, когда нужно было что-то поменять в пайплайне (а делать это приходилось часто, так как проект динамичный и быстро развивался), мы проходились по 20 репозиториям и поправляли всё вручную. Это довольно геморройный процесс, и мы подумали: «А почему бы нам не сделать что-то общее?».

Так мы перешли на Jenkins Shared Library. У нас появился базовый пайплайн в библиотеке, и, когда требовалось что-то изменить, мы работали с ним. Добавляли какие-то правки, и они автоматически имплементировались в каждый микросервис.

Ограничения Jenkins Shared Library

Любой инструмент призван решать какую-то проблему. Jenkins Shared Library решает проблему дублирования кода и унификации. Если вам эта унификация не нужна, смысла тащить библиотеку в проект нет.

Если, скажем, у вас небольшой проект, где всего 5 микросервисов, писать для него библиотеку с нуля не стоит. Единственный вариант — переиспользовать, если она уже написана. Jenkins Shared Library — всё-таки решение для более крупных проектов с большим количеством микросервисов.

Кейс: разработка и тестирование Jenkins Shared Library

Для разработки и тестирования Jenkins Shared Library нам необходимо установить на свой компьютер gradle. Вот инструкция по установке — https://gradle.org/install/.

Далее в рабочем каталоге мы выполняем команду инициализации «gradle init», говорим установщику, что хотим настроить base каталог с groovy-файлами, и получаем готовый проект.

Следующий шаг — создание каталогов для JSL:

Директория src используется для Groovy классов, которые добавляются в classpath.

Директория resources содержит файлы, которые мы можем загружать в пайплайн.

Директория test содержит тесты для наших скриптом.

Директория vars используется в скриптах, которые определяют глобальные переменные, доступные из пайплайна.

Затем заполянем build.gradle, добавляя в него описание наших каталогов:

–— sourceSets < main < groovy < srcDirs = [‘src’,’vars’] >resources < srcDirs = [‘resources’] >> test < groovy < srcDirs = [‘test’] >> > —

И добавляем зависимости, которые понадобятся нам в работе. Полный файл можно посмотреть в репозитории: ссылка на репозиторий.

Пишем простой первый класс, который увеличивает возраст на указанное значение 🙂

package com.example class SampleClass < String name Integer age def increaseAge(Integer years) < this.age += years >>

Не забываем про тесты — создаем в директории test файл с именем SampleClassTest.groovy и содержимым.

В секции Before описываем действия, которые необходимо выполнить перед тестом — в нашем случае это объявление класса. Далее в секции Test описываем сам тест. Объявляем age = 7 и выполняем функцию increaseAge с параметром 3. В случае правильного выполнения ожидаем получить 10.

Тест готов, запускаем командой gradle test. Результат будет такой:

Но это синтетические примеры, давайте рассмотрим реальный

Каждый раз для вызова GET или POST запроса в пайплайн нам нужно вызывать класс HttpsURLConnection, передавать в него правильные параметры и проверять валидность сертификата.

Последуем главному принципу программирования DRY и подготовим класс, который позволит нам вызывать get и post запросы в пайплайне.

Создаем в директории src/com/example HttpsRequest.groovy, в нём создаем два метода get и post. В параметрах методов передаём URL-запроса и в случае POST еще и body-запроса.

Корневым методом нашего класса будет метод httpInternal. В нём закладываем логику, добавляем параметры к HttpsURLConnection, отлавливаем ошибку и в результате возвращаем тело ответа и ошибку:

package com.example import groovy.json.JsonSlurper import javax.net.ssl.HttpsURLConnection import javax.net.ssl.SSLContext import javax.net.ssl.TrustManager import javax.net.ssl.X509TrustManager import java.security.cert.CertificateException import java.security.cert.X509Certificate class HttpsRequest < def get(String uri) < httpInternal(uri, null, false) >def post(String uri, String body) < httpInternal(uri, body, true) >def httpInternal(String uri, String body, boolean isPost) < def response = [:] def error try < def http = new URL(uri).openConnection() as HttpsURLConnection if (isPost) < http.setRequestMethod(‘POST’) http.setDoOutput(true) if (body) < http.outputStream.write(body.getBytes(«UTF-8»)) >> http.setRequestProperty(«Accept», ‘application/json’) http.setRequestProperty(«Content-Type», ‘application/json’) http.connect() if (http.responseCode == 200) < response = new JsonSlurper().parseText(http.inputStream.getText(‘UTF-8’)) >else < response = -1 >> catch (Exception e) < println(e) error = e >return [response, error] > >

Покрываем тестами и создаем файл в директории test/HttpsRequestTest.groovy.

Для примера делаем get запрос, получаем ответ и проверяем, что он соответствует нашим ожиданиям:

void testGet() < def expect = json.parseText(») def (result, error) = http.get(«https://run.mocky.io/v3/0bd64f74-1861-4833-ad9d-80110c9b5f25») if (error != null) < println(error) >assertEquals «result:», expect, result >

Осталось дело за малым — подключить библиотеку в Jenkins.

Для этого в Jenkins нужно перейти: Manage Jenkins → Configure System (Настроить Jenkins → Конфигурирование системы). В блоке Global Pipeline Libraries, добавить наш репозиторий:

Последний шаг — создаем наш пайплайн:

Весь код можно найти в репозитории: ссылка на репозиторий.

Вместо заключения: о чём нужно помнить при работе с Jenkins Shared Library

Jenkins Shared Library — больше инструмент разработки в том плане, что нужно программировать. Чаще всего когда вы первый раз работаете с ней, если вы не разработчик, а администратор или DevOps, вы делаете это по наитию с точки зрения администратора. Это рабочий подход, но у него есть свои недостатки. Например, расширять проект дальше сложнее.

Лучше сразу начинать мыслить как разработчик: выделять классы и методы, правильно их имплементировать в пайплайн и т.д. Если вы не из мира разработки, это осознание приходит с запозданием. И чем позже оно придёт, тем больше времени и сил вы потратите на то, чтобы переписать то, что уже сделали.

Для тех, кто хочет углубиться в тонкости работы с Jenkins Shared Library и получить скидку 10% на обучение

6 сентября у нас стартует курс по Jenkins, автором которого выступил Кирилл Борисов, Infrastructure Engineer технологического центра Deutsche Bank. В курсе будет много кейсов и примеров из практики спикера.

• автоматизировать процесс интеграции и поставки;
• ускорять цикл разработки и внедрять полезные инструменты;
• настраивать плагины и создавать пайплайны Jenkins as a code;
• работать с Jenkins Shared Library.

Промокод «READER» даёт скидку 10% при покупке курса.

Источник: habr.com

Где Ubuntu ищет разделяемые библиотеки?

Общие библиотеки — это скомпилированный код, предназначенный для совместного использования несколькими различными программами. Они распространяются как. so файлы в / usr / lib /. Библиотека экспортирует символы, которые являются скомпилированными версиями функций, классов и переменных.

Где Linux ищет разделяемые библиотеки?

В Linux это / lib / ld-linux. так. x ищет и загружает все разделяемые библиотеки, используемые программой. Программа может вызывать библиотеку, используя ее имя или имя файла, а в пути к библиотеке хранятся каталоги, в которых библиотеки могут быть найдены в файловой системе.

Как узнать, какие библиотеки установлены в Ubuntu?

Процедура перечисления пакетов, установленных в Ubuntu:

Где GCC ищет разделяемые библиотеки?

Он просматривает каталоги по умолчанию / lib, затем / usr / lib (отключено параметром компоновщика -z nodeflib).

• Что такое позиционно-независимый код? …
• GCC сначала ищет библиотеки в / usr / local / lib, затем в / usr / lib. …
• Загрузчик GNU по умолчанию, ld.so, ищет библиотеки в следующем порядке: ↩

Где компоновщик ищет библиотеки?

По умолчанию компоновщик среды выполнения знает только одно стандартное место для поиска библиотек, / usr / lib при обработке 32-битных объектов и / usr / lib / 64 при обработке 64-битных объектов. Все остальные каталоги для поиска должны быть явно добавлены в путь поиска компоновщика среды выполнения.

Как узнать, какие библиотеки установлены в Linux?

Параметр -v покажет версию библиотеки.

Что такое разделяемые библиотеки в Linux?

Общие библиотеки — это библиотеки, которые можно связать с любой программой во время выполнения. Они предоставляют средства для использования кода, который можно загрузить в любом месте памяти. После загрузки код разделяемой библиотеки может использоваться любым количеством программ.

Как узнать, какие пакеты Python установлены в Ubuntu?

В ubuntu: sudo apt-get install python-pip, если он еще не установлен. И оба покажут вам все установленные модули и их версии.

Источник: frameboxxindore.com

Shared libraries что это за программа

Этот фрагмент makefile добавляет цель install, то есть теперь можно выполнить команду make install и библиотека будет установлена в /usr/lib.

• Команда «install» копирует заданный файл библиотеки по заданному пути и создает символьную ссылку на него с именем, заданным в soname. Опция -m позволяет задать также права доступа для файла (644 — разрешение на запись и чтение для владельца файла, чтение для пользователей той же группы, чтение для остальных пользователей).
• Команда «sudo ln -sf» создает символьную ссылку с перезаписью существующей (если такая уже есть) на файл только что установлненой библиотеки с именем для компилятора (soname без версии). После этой команды в заданном каталоге присутствуют файлы библиотеки со всеми тремя ранее перечисленными именами.
• Команда «sudo ldconfig -n» перечитывает заданный каталог (опция -n) и обновляет кэш. После этого линкер и другие программы могут запрашивать библиотеку по имени (например, по soname). Можно вывести список всехъ загруженных библиотек с помощью команды «ldconfig -p».
• Далее в случае необходимости можно скопировать заголовочные файлы библиотеки.
• Цель «install» должна создаваться как phony-target (потому, что в результате ее выполнения не собирается новый файл).

Источник: dgrafov.blogspot.com