Ошибка блога 404
-
Похожий контент
-
От mamruc
Здравствуйте!
Физически помер сервер с установленным KSC14, есть бекап сервера. На новом сервере устанавливал KSC с новой базой, при подключении через Веб морду ничего не отображает, через MMC пишет:
«Операция не может быть выполнена, так как программа инициализируется или деинициализируется»
Такой статус еже несколько часов.
-
От SDDdo
Здравствуйте! Есть внешний HDD диск. Во время загрузки файлов на этот диск произошло непреднамеренное отключение диска из USB разъема. При повторном подключении диска, система не видит диск в проводнике, в диспетчере устройств диск отображается, но с другим именем. В управлении дисками при попытке инициализировать диск выдает ошибку CRC. Возможно ли решить данную проблему своими силами?
-
-
От ГГеоргий
Добрый день!
Проводим переезд KSC на новую бд
для этого полностью удалили KSC и ставим с нуля
KSC будет на WINserv2016
BD - PostgreSQL 15 на Rocky linux 9 (До этого стояла на WinServ 2016, что не подходило под требования CIS)
предварительные настройки на стороне BD выполнены
(а именно: создана бд и учетка к ней, изменен конфигурационный файл и созданы юзеры в смой системе)
при установке возникает такая проблема
В процессе установки произошла ошибка: Generic db error: "[42501]`ОШИБКА: нет доступа к схеме public `, LastStatement=`CREATE PROCEDURE "AK_RAISERROR"( ) LANGUAGE plpgsql
судя по объяснению, проблема в том что у пользователя, под которым я выполняю установку KSC, нет необходимых прав доступа к схеме public в базе данных PostgreSQL.
однако это не так
я выполнил создание бд и пользователя:
CREATE USER "KSCAdmin" WITH PASSWORD 'testpass@123';
CREATE DATABASE "KAV" ENCODING 'UTF8';
GRANT ALL PRIVILEGES ON DATABASE "KAV" TO "KSCAdmin";
затем перешел в саму БД KAV и выполнил:
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA "public" TO "KSCAdmin";
GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA "public" TO "KSCAdmin";
вывод терминала:
[admin@localhost ~]$ sudo psql -U KSCAdmin KAV
[sudo] пароль для admin:
Пароль пользователя KSCAdmin:
psql (15.8)
Введите "help", чтобы получить справку.
KAV=> GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA "public" TO "KSCAdmin";
GRANT
KAV=> GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA "public" TO "KSCAdmin";
GRANT
-
От KL FC Bot
Серьезные ИБ-инциденты порой затрагивают многих участников, зачастую и тех, кто повседневно не занимается вопросами ИТ и ИБ. Понятно, что в первую очередь усилия сосредоточиваются на выявлении, сдерживании и восстановлении, но, когда пыль немного осядет, наступает время для еще одного важного этапа реагирования — извлечения уроков. Чему можно научиться по итогам инцидента? Как улучшить шансы на успешное отражение подобных атак в будущем? На эти вопросы очень полезно ответить, даже если инцидент не принес существенного ущерба из-за эффективного реагирования или просто удачного стечения обстоятельств.
Немного о людях
Разбор инцидента важен для всей организации, поэтому к нему обязательно привлекать не только команды ИТ и ИБ, но также высшее руководство, бизнес-владельцев ИТ-систем, а также подрядчиков, если они были затронуты инцидентом или привлекались к реагированию. На встречах этой рабочей группы нужно создать продуктивную атмосферу: важно донести, что это не поиск виноватых (хотя ошибки будут обсуждаться), поэтому перекладывание ответственности и манипулирование информацией исказят картину, повредят анализу и ухудшат позицию организации в долгосрочной перспективе.
Еще один важный момент: многие компании скрывают детали инцидента в страхе за репутацию или опасаясь повторной кибератаки по тому же сценарию. И хотя это вполне объяснимо и некоторые подробности действительно конфиденциальны, нужно стремиться к максимальной прозрачности в реагировании и делиться подробностями атаки и реагирования если не с широкой публикой, то как минимум с узким кругом коллег из сферы ИБ, которые могут предотвратить похожие атаки на свои организации.
View the full article
-
Рекомендуемые сообщения
Пожалуйста, войдите, чтобы комментировать
Вы сможете оставить комментарий после входа в
Войти