Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request #15

Open
3 of 5 tasks
jacklul opened this issue Apr 17, 2017 · 10 comments
Open
3 of 5 tasks

Feature request #15

jacklul opened this issue Apr 17, 2017 · 10 comments

Comments

@jacklul
Copy link

jacklul commented Apr 17, 2017

@noplanman
Copy link
Member

noplanman commented Apr 18, 2017

Please add some extra explanations for each bit 👍

Add getWebhookInfo result to GET/CLI parameters action

So every request does an extra request for the webhook info?
If so, I think we wait for the options table to be implemented, to offer an easy way to cache the value at least.

Categorize config array #13 (comment)

Will be done 🎉

Botan options

This one is easy to implement, just need to know what options you'd like to have in here, as I'm not very familiar with Botan.

Log rotator

As in, define a maximum size of log file before it gets rotated? Or line count?
Something simple it must be 😉

Build-in log/exception reporter to admins ?

So that admins get a message every time an exception happens?

@jacklul
Copy link
Author

jacklul commented Apr 18, 2017

Add getWebhookInfo result to GET/CLI parameters action

What I mean is manager.php a=info that shows the webhook info.

Botan options

Simply array for options that will be passed to enableBotan()

Log rotator

Well, let the user choose in this case:

Build-in log/exception reporter to admins ?

This I meant as a addition to rotator, maybe the user could specify if he wants the log to be sent when it reaches xx size, xx lines or becomes xx seconds old or send log that got rotated and archived.

@noplanman
Copy link
Member

noplanman commented Apr 20, 2017

a=info is really pointing towards making a better CLI tool for the bots. Something like WP-CLI (which you might now, and @lichtscheu most probably). It's a CLI for WordPress, which makes administration a breeze, and being able to execute commands without having to load the entire CMS.

As for the config array, I've put some thought into it and have come up with this merged version of your ideas with mine.
I've moved the commands paths into the commands section, not 100% sure about that one yet, as it would fit perfectly into the paths one too 😕
Also, for cron I've made groups, so that different commands could be grouped and executed together.
Give me you feedback on this!

$config = [
    // Basics
    'api_key'      => getenv('BOT_API_KEY'),
    'bot_username' => getenv('BOT_USERNAME'),
    'secret'       => getenv('BOT_SECRET'),

    // Paths
    'paths'        => [
        'download' => ROOT_PATH . '/download/',
        'upload'   => ROOT_PATH . '/upload/',
    ],

    // Database
    'mysql'        => [
        'host'     => getenv('DB_HOST'),
        'user'     => getenv('DB_USER'),
        'password' => getenv('DB_PASS'),
        'database' => getenv('DB_NAME'),
        //'table_prefix' => getenv('DB_TABLE_PREFIX'),
        //'encoding'     => getenv('DB_ENCODING'),
    ],

    // Webhook
    'webhook'      => [
        'url'             => getenv('BOT_WEBHOOK'),
        //'certificate'     => 'certificate.crt',
        'max_connections' => 100,
        'allowed_updates' => ['message', 'edited_message', 'inline_query', 'chosen_inline_result', 'callback_query'],
    ],

    // Logging
    'logging'      => [
        'error' => ROOT_PATH . '/logs/Error.log',
        //'debug'  => ROOT_PATH . '/logs/Debug.log',
        //'update' => ROOT_PATH . '/logs/Update.log',
    ],

    // Settings
    'admins'       => [(integer) getenv('BOT_ADMIN')],

    // Commands
    'commands'     => [
        'paths'   => [
            ROOT_PATH . '/Commands/',
        ],
        'configs' => [
            'randomcommand' => [
                'api_key' => getenv('RANDOM_COMMAND_API_KEY'),
            ],
        ],
    ],

    // Extra features
    'botan'        => [
        'token'   => getenv('BOTAN_TOKEN'),
        'options' => [
            'timeout' => 1,
        ],
    ],
    'limiter'      => [
        'enabled' => true,
        'options' => [
            'interval' => 0.5,
        ],
    ],

    // Cron
    'cron'         => [
        'groups' => [
            'default'     => [
                '/somecommand',
            ],
            'maintenance' => [
                '/cleanup',
                '/sendlogs',
            ],
            'groupx'      => [
                '/commandx',
            ],
        ],
    ],
];

This I meant as a addition to rotator, maybe the user could specify

Ok, this one could be challenging to make "simple". The more possible options/settings, the more complex everything becomes, obviously.

@jacklul
Copy link
Author

jacklul commented Apr 20, 2017

Definitely loving cron groups idea!

PS. Whoops.

@jacklul jacklul closed this as completed Apr 20, 2017
@jacklul jacklul reopened this Apr 20, 2017
@jacklul
Copy link
Author

jacklul commented Apr 20, 2017

Oh! Another!

It would be nice to be able to pass own PDO instance with $config array!

Also why we have to use a=set in CLI ?
It would make more sense to allow manager.php set which would be much simplier!

@noplanman
Copy link
Member

Oh just saw this now:

It would make more sense to allow manager.php set which would be much simplier!

I totally agree with you! The reason why it is as it is at the moment, is that I can use the exact same code to handle CLI input and direct webhook calls.
i.e.
manager.php?a=set === php manager.php a=set

I know that this will change to what you proposed, but first we should establish base commands and then work on a true CLI app that can be packaged as a phar.
This is still quite a bit in the future, but my idea was to be able to manage any bot installation using a general CLI command.

@noplanman
Copy link
Member

@jacklul Regarding log rotation, Monolog has a very simple rotator, that rotates daily.

// instead of
(new StreamHandler(__DIR__ . '/debug.log', Logger::DEBUG))->setFormatter(new LineFormatter(null, null, true)),

// we can use the rotator (keeping 5 days of logs in this example)
(new RotatingFileHandler(__DIR__ . '/debug.log', 5, Logger::DEBUG))->setFormatter(new LineFormatter(null, null, true)),

I've been reading online that the best method is to use a dedicated logrotate setup.

@jacklul
Copy link
Author

jacklul commented Aug 8, 2020

@jacklul Regarding log rotation, Monolog has a very simple rotator, that rotates daily.

// instead of
(new StreamHandler(__DIR__ . '/debug.log', Logger::DEBUG))->setFormatter(new LineFormatter(null, null, true)),

// we can use the rotator (keeping 5 days of logs in this example)
(new RotatingFileHandler(__DIR__ . '/debug.log', 5, Logger::DEBUG))->setFormatter(new LineFormatter(null, null, true)),

I've been reading online that the best method is to use a dedicated logrotate setup.

I agree

@Leonid74
Copy link

Leonid74 commented Aug 8, 2020

Perhaps this will help someone, I use an even simpler mechanism - I specify the date at the beginning of the file name for easy perception, like this:

(new Monolog\Handler\StreamHandler(__DIR__ . '/logs/' . date('Y-m-d') . '_error.log', Monolog\Logger::ERROR))->setFormatter(new Monolog\Formatter\LineFormatter(null, null, true)),

and using cron (that runs daily), I delete logs older than 10 days

find /path/to/logs/dir/ -mtime +10 -type f -name "*error.log" -delete >/dev/null 2>&1

@noplanman
Copy link
Member

Great idea @Leonid74 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants