852 ответов в теме

[Karmael]

зачем экспорты в объявлении переменных, там еще кто то пользуется этими переменными? если все в рамках одного скрипта, выпили. 

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

лел, а вот сейчас было нижепояса, захожу я значится проверить гуглопочту, а там после наших тут с вами терок пучек спама висит в "важных" и "уникальных" , и от кого , казалось бы!!11

 

Михаель Алессио

GitLab

Директор по развитию партнерской сети

 

[Naimas Alvares]

захожу я значится проверить гуглопочту

 

Он сегодня всем написал. И прям жаждет пообщаться

 

edit: не то зацитировал.

Сообщение отредактировал Naimas Alvares: 11 October 2016 - 21:50

[koraven]

Ну скажем так. Если логов мало, то тут и обычного syslog > текстовый файл хватит, главное не забывать про логротейт.

Если логов уже столько что поиск нужной инфы начинает занимать неприлично много времени, даже с учетом мастерского владения грепом, то тут нужна связка syslog+mysql Опять же появляется возможность уже делать красивые графики, индикаторы, и прочие дашборды. Если такая связка не справляется - то уже пора думать что мы выросли в серьезный энтерпрайз а значит системы анализа и кореляции логов нам нужны, да. А все нормальные - денег стоют. Зато значительно упрощают расследование всякого.

Ты не пробовал гуглить перед тем как отвечать? Если бы ты погуглил, что такое ELK, хотя бы узнал значение первой буквы, то явно не писал бы  "тут нужна связка syslog+mysql" и не предлагал бы энтерпрайз как следующую ступень за mysql.

Сообщение отредактировал koraven: 11 October 2016 - 21:49

[Slotos]

ELK тоже не справился?

Его тогда ещё не было, если мы про Elastic stack. Да и он как раз хранение логов и распарсенной информации вроде не путает.
 

Ага, целая тулза - баш скрипт ажно в 12 строчек:
 

#!/bin/sh
export BACKUP_DIR="/media/rsync/data/BackUp/CloudSigma"
export REMOVE_OLD_DAYS 120
export IP_ADDR 10.8.0.1
export IP_PORT="2222"
file_name=`LC_ALL=en_US.utf8 date '+%h_%d_%Y'`.txt
ssh -p $IP_PORT $IP_ADDR "export compact" > $BACKUP_DIR/$file_name
cp -f $BACKUP_DIR/$file_name $BACKUP_DIR/last/backup.txt
sed -i "1,1d" $BACKUP_DIR/$file_name
fdupes -dN $BACKUP_DIR > /dev/null 2>&1
find $BACKUP_DIR -type f -mtime +$REMOVE_OLD_DAYS -exec rm -f {} \;
echo "Subject: CloudSigma Backup\nFinished" | /usr/lib/sendmail root
#end

Если этот бекап скрипт полностью описывает твою профессиональную деятельность - гит тебе не нужен.

[Karmael]

там кстати косяк все равно в половине экспортов, в половину переменных ничего не попадет

[vmarkelov]

Если этот бекап скрипт полностью описывает твою профессиональную деятельность - гит тебе не нужен.

Ахтунг! Это дома.

там кстати косяк все равно в половине экспортов, в половину переменных ничего не попадет

Ять. Миа кульпа, посыпаю голову пеплом.
Заменял с телефона реальные значения, понаудалял не то.

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

Это, может я в чем то ошибаюсь, но разве эти переменные видны не только в контексте этого скрипта?

Ты не пробовал гуглить перед тем как отвечать? Если бы ты погуглил, что такое ELK, хотя бы узнал значение первой буквы, то явно не писал бы "тут нужна связка syslog+mysql" и не предлагал бы энтерпрайз как следующую ступень за mysql.

Пробовал. Далее мое имхо: если допиленная связка syslog+mysql уже не справляется, то значит eps такой, что уже не достаточно просто складировать и просматривать. Шанс профакапить чего-нибудь полезное близок к 100%. Нужны корреляции, сигнатуры, оповещения и тд, то есть нужен siem. Аналогов бесплатных я к сожалению не знаю.

[Karmael]

export объявляет переменные наружу, в этом весь его смысл в рамках одного скрипта достаточно просто 

TMP="/tmp"

[vmarkelov]

export объявляет переменные наружу, в этом весь его смысл в рамках одного скрипта достаточно просто
TMP="/tmp"

# ./backup_cs.sh
# echo $IP_ADDR
 
#

Так что не наружу точно. А видна она только в пределах текущего скрипта и вызываемых из него скриптов/программ.

[Naimas Alvares]

Так что не наружу точно. А видна она только в пределах текущего скрипта и вызываемых из него скриптов/программ.

 

 

Наружу для дочерних процессов. Т.е. если ты из него еще один срипт запустишь на выполнение, то он уже получит environment измененный этим скриптом (из-за экспортов), а если убрать экспорт, то получит родительский чистый. Внутри скрипта переменные отработают и без экпорта. Т.е. просто не совсем понятно зачем их помечать для экспорта в дочерние процессы, если этого не надо (хотя в конкретном случае, как бы никаких проблем).

 

Получил environment при старте процесса. Переопределил/ввел переменные (=). И отработал. Этого достаточно.

 

PS: а если через крон запускаешь, то еще из хороших практик все вызываемые проги также в шапке в переменные засунуть с полными путями, и по именам переменных вызывать.

[Karmael]

$ a=linuxcareer.com
$ echo $a
linuxcareer.com
$ export a
$ bash
$ echo $a
linuxcareer.com
$

-------------------------------< no export

$ a=linuxcareer.com
$ echo $a
linuxcareer.com
$ bash
$ echo $a

$

Сообщение отредактировал Karmael: 12 October 2016 - 9:12

[vmarkelov]

$ a=linuxcareer.com
$ echo $a
linuxcareer.com
$ export a
$ bash
$ echo $a
linuxcareer.com
$
-------------------------------< no export
$ a=linuxcareer.com
$ echo $a
linuxcareer.com
$ bash
$ echo $a
$

Да, именно так.

Т.е. просто не совсем понятно зачем их помечать для экспорта в дочерние процессы, если этого не надо (хотя в конкретном случае, как бы никаких проблем).

Что б когда я в состоянии угара начну этот скрпит разбивать на сотню маленьких иметь единое пространство переменных.

[Tir]

...
find $BACKUP_DIR -type f -mtime +$REMOVE_OLD_DAYS -exec rm -f {} \;
...

Зачем ты насилуешь fork?

[vmarkelov]

Зачем ты насилуешь fork?

Переведи, плз. Эта строчка просто удаляет старые конфиги.

[r0n1]

с текстовыми доками редко приходится иметь дело, чаще с табличками. и вот тут у меня от экселя брат умер  изжога. Почему до сих пор нет внятного конфигурируемого открытия csv, а разделитель захардкоден?

 че? ты не пробовал там глазами посмотреть, например поискать поле где можно указать тот разделитель который тебе нужен?

при работе с документами в LO/OO как раз больше проблем вызывают адепты офиса с форматированием энтерами и пробелами, Лично не сталкивался с косяками в работе с документами с правильной структурой, но отрицать проблемы с переносимостью глупо. Чего уж там, если между разными версиями мс офис нет 100% переносимости...

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

Сообщение отредактировал r0n1: 12 October 2016 - 12:39

[Tir]

Переведи, плз. Эта строчка просто удаляет старые конфиги.

И насилует fork. Если заглянуть в man find, можно узнать, что "\;" после -exec в find-е запускает вот то, что ты в -exec-е написал, для каждого найденного файла. В твоём случае для каждого найденного файла форкается процесс, в котором запускается rm. fork - дорогая операция, влекущая создание процесс контекста, который потом ещё луниксу придётся уничтожить, когда rm отработает. Между тем, если заглянуть в man rm, можно узнать, что rm-у можно скормить сразу целый список файлов на удаление. А если потом снова заглянуть в man find, можно узнть, что после -exec можно написать "+" вместо "\;", что заставит find дописывать имена всех найденных файлов в конец команды, вызываемой exec-ом. Так можно перестать насиловать fork find-ом.

[r0n1]

а если еще немного почитать ман, то можно найти и опцию -delete

а если использовать exec+ то можно упереться в лимит аргументов

Сообщение отредактировал r0n1: 12 October 2016 - 12:47

[vmarkelov]

И насилует fork. Если заглянуть в man find, можно узнать, что "\;" после -exec в find-е запускает вот то, что ты в -exec-е написал, для каждого найденного файла. В твоём случае для каждого найденного файла форкается процесс, в котором запускается rm. fork - дорогая операция, влекущая создание процесс контекста, который потом ещё луниксу придётся уничтожить, когда rm отработает. Между тем, если заглянуть в man rm, можно узнать, что rm-у можно скормить сразу целый список файлов на удаление. А если потом снова заглянуть в man find, можно узнть, что после -exec можно написать "+" вместо "\;", что заставит find дописывать имена всех найденных файлов в конец команды, вызываемой exec-ом. Так можно перестать насиловать fork find-ом.

А теперь учитываем что это выполняется раз в день и соответсвенно либо не удаляет ничего, либо 1(один) файл.

[Naimas Alvares]

А теперь учитываем что это выполняется раз в день и соответсвенно либо не удаляет ничего, либо 1(один) файл.

 

Блин, да изначально весь разговор то про хорошие практики. А то в итоге можно было остановиться на Кармовском "хлебать ботинком".

[vmarkelov]

Блин, да изначально весь разговор то про хорошие практики. А то в итоге можно было остановиться на Кармовском "хлебать ботинком".

Угу. У нас есть "продукт-нейм" и мы будем им затыкать все дырки к которым он хоть как-то подходит, невзирая на окружающие условия, их особенности и прочие мелочи. Ибо продукт "тру"! Ибо так написано на лоре!

[Naimas Alvares]

Угу. У нас есть "продукт-нейм" и мы будем им затыкать все дырки к которым он хоть как-то подходит, невзирая на окружающие условия, их особенности и прочие мелочи. Ибо продукт "тру"! Ибо так написано на лоре!

 

Ты опять перескакивашь куда-то. Что за привычка? Тир про форк отписал тебе, ты отмазался тем, что оно в данном случае дешево обходится. Ну дешево! Но нафига? Экспорт в скрипте лишний, но безобидный. Да, может пригодиться при дроблении - но ведь тогда и экспортировать можно, сейчас то он нагрузки смысловой не несет - нафига?

 

PS: наверняка же сам понимаешь, что из таких мелочей потом вырастает рукожопство и затыки. Почему самому себя не научить сразу делать правильно. Этож кайфно, когда понимаешь, что у тебя все сделано офигенно.

Сообщение отредактировал Naimas Alvares: 12 October 2016 - 13:32