Используя Мерзавца без Sudo во многих учетных записях

У нас есть что-то подобное, реализованное в нашей системе. Мы храним определенные регистраторы в HashMap и инициализируем appenders для каждого из них по мере необходимости.

Вот пример:

public class JobLogger {
private static Hashtable<String, Logger> m_loggers = new Hashtable<String, Logger>();
private static String m_filename = "...";  // Root log directory

public static synchronized void logMessage(String jobName, String message)
{
    Logger l = getJobLogger(jobName);
    l.info(message);
}

public static synchronized void logException(String jobName, Exception e)
{
    Logger l = getJobLogger(partner);
    l.info(e.getMessage(), e);
}

private static synchronized Logger getJobLogger(String jobName)
{
    Logger logger = m_loggers.get(jobName);
    if (logger == null) {
        Layout layout = new PatternLayout("...");
        logger = Logger.getLogger(jobName);
        m_loggers.put(jobName, logger);
        logger.setLevel(Level.INFO);
        try {
            File file = new File(m_filename);
            file.mkdirs();
            file = new File(m_filename + jobName + ".log");
            FileAppender appender = new FileAppender(layout, file.getAbsolutePath(), false);
            logger.removeAllAppenders();
            logger.addAppender(appender);
    }
        catch (Exception e)
    { ... }
    }
    return logger;
}
}

Затем для использования этого в задании просто необходимо использовать одну запись строки как это:

JobLogger.logMessage(jobName, logMessage);

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

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

11
задан hhh 2 September 2009 в 11:53
поделиться

4 ответа

Если я правильно понял ваш вопрос, вам необходимо предоставить нескольким учетным записям пользователей * nix доступ на запись в один и тот же репозиторий git. Использование аргумента командной строки - share для git init должно включить это. В GitWiki есть несколько слов, чтобы сказать об этом . Это должно сработать:

git --bare init --shared=all

Если вы уже создали свой репозиторий, вы можете преобразовать его в «общий репозиторий», введя следующую команду:

git repo-config core.sharedRepository true

в вашем репозитории, как упоминалось в блоге сообщение на moserei.de .

Обновление 2014 г .: Использование аргумента командной строки - share для git init должно включить это. В GitWiki есть несколько слов, чтобы сказать об этом . Это должно помочь:

git --bare init --shared=all

Если вы уже создали свой репозиторий, вы можете преобразовать его в «общий репозиторий», введя следующую команду:

git repo-config core.sharedRepository true

в вашем репозитории, как упоминалось в блоге сообщение на moserei.de .

Обновление 2014 г .: Использование аргумента командной строки - share для git init должно включить это. В GitWiki есть несколько слов, чтобы сказать об этом . Это должно помочь:

git --bare init --shared=all

Если вы уже создали свой репозиторий, вы можете преобразовать его в «общий репозиторий», введя следующую команду:

git repo-config core.sharedRepository true

в вашем репозитории, как упоминалось в блоге сообщение на moserei.de .

Обновление 2014 г .: Это все еще возможно, но команда была изменена с repo-config на config.

git config core.sharedRepository true
18
ответ дан 3 December 2019 в 02:20
поделиться

Git предназначен для распространения. Таким образом, у каждого пользователя должен быть собственный репозиторий. Приведенный выше метод противоречит этой методологии. Кроме того, я подозреваю разрешения каталога .git .

7
ответ дан 3 December 2019 в 02:20
поделиться

Я предполагаю, что проблема заключается в праве собственности на каталог .git .

Вы не должны использовать одно дерево исходного кода от разных пользователей - это может привести к проблемы.

Исполняемый файл git не является проблемой. Он должен принадлежать пользователю root и иметь 755 разрешений. ( -rwxr-xr-x )

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

5
ответ дан 3 December 2019 в 02:20
поделиться

Наличие прав доступа к любому набору исполняемых файлов, позволяющих обычному пользователю перезаписать исполняемый файл, представляет собой значительный риск для безопасности. (Попробуйте перезаписать / usr / bin / git сценарием оболочки, который вызывает rm -rf $ HOME .)

Измените права доступа обратно на 755 и сделайте git владельцем root: снова рут. (Диспетчер пакетов Ubuntu все равно сбросит разрешения при следующем обновлении, если вы не использовали dpkg-statoverride (8) )

Я согласен с теми, кто говорит, что, возможно, иметь несколько пользователей - плохая идея. поделитесь одним репозиторием git. Если вы все еще считаете, что это необходимо, рассмотрите возможность создания новой группы, chgrp , каталога, содержащего репозиторий и все файлы в нем для этой группы, и установите бит setgid для каталогов.

3
ответ дан 3 December 2019 в 02:20
поделиться
Другие вопросы по тегам:

Похожие вопросы: