Banned, Not In Corp Pilot on Mapper

[eophten]

We have a banned (in pathfinder), not in corp pilot who continues to appear on our mapper. This pilot has been out of corp for +7 days.

[exodus4d]

@eophten Thanks for your issue:

1. What means "in pathfinder"? is he visual on the map, moving around? Just visible in some tables e.g. "scan statistics"? Still visible inside the /admin page?

[eophten]

More information:

This pilot is no longer in corp. We have banned him through the pathfinder /admin interface. He still displays as in corp within the pathfinder /admin page. He is visible on the map (always in Jita), although we do not see him moving around. His character triggers a connection from home hole to Jita periodically if we delete Jita from the mapper. Last login in /admin reflects when we removed him from corp.

Our current work around is to leave Jita on the mapper but detached from the chain and his character remains in that system.

[exodus4d]

Ok thanks. One more question:

• I guess this happens on the official server right? - could you please tell me the Character´s name ([email protected]), this would help me to figure out what happens by checking log files.

In the meantime I´ll try to reproduce this on my local dev-server...

For now, don´t worry! The lastLogin timestamp, shown at the /admin page is not the inGame login timestamp. It represents the last login on Pathfinder.
If a character was banned, it should be kicked out of PF immediately (if he is currently logged in) and should not be able to Log into until:

1. He changed his Corp and the new Corp is not blacklisted by the Server.
2. Someone revokes the kick/ban on the /admin page
3. He "sold" his Character, CCP transfers the Character to a new Owner and then tries to log into PF again (very unlikely!). But This is needed for e.g. a public installation like mine.

But all of this does not explain the auto-generated Jita connection.

If this happens on a private server:

• Which PF version is installed?
• Please double check if your Cronjob is configured right and running (check PHP error logs, and PFs Chronjob log file for last execution /logs/cron.log).

[eophten]

@exodus4d this is on a private server running pathfinder v1.5.3, ubuntu 18.04 (ec2), amazon rds mysql 8.0.16

I can provide log files, db access, or pathfinder access if required.

We have setup the server with pathfinder.login limited based on corporation ID and that confirms how I expected the lastLogin to work (so I have no security concerns).

* * * * * cd /opt/www/pathfinder/; sudo -u www-data php index.php /cron >> /var/log/cron-www/pathfinder.log 2>&1

pathfinder.log has not been written to recently (there were some errors during initial setup). Executing the command manually runs/exits without error (although there is no output indicating success). Is there a database value that I can query for last success? Is it possible to add output (timestamp, debugging output, etc.) and I can set up log rotation?

[exodus4d]

Thanks. Your Cronjob setup looks right!
I guess your problem relates to #830 which will be fixed in the next version.
You should manually replace one line of code, wait 5min (for the next cronjob trigger) and see if the character disappear from map: e32bc21

Explanation:

All PHP files in app/main/cron/ contain standalone cronjob methods that will be triggered by the main cronjob at its time.
All of them are configured in cron.ini (and should not be changed!).

In your case deleteLogData() should be triggered @instant (= * * * * * == every minute)

pathfinder/app/cron.ini

Line 33 in 7d11851

deleteLogData = Cron\CharacterUpdate->deleteLogData, @instant

For testing (or development), you can run each of these manually vom CLI (Terminal). The command for manually execution of a single Cronjob method is always mentioned in the code documentation above. check: characterupdate.php#L39

php index.php "/cron/deleteLogData"

Simple, cd to the Pathfinders [root] dir (where index.php is located), and run this command.
In your case Unix users www-data or root should be used for that.
Any debug output you have added should be visible in your Terminal.

Log rotation

There is a core log file updated every time a cronjob was executed: logs/cron.log.
In addition there are multiple logs/cron_*.log files written by some cronjob methods, too. (In your case deleteLogData() does not have its own cron_deleteLogData.log file! - because it runs to frequently - every minute).

Adding Logrotate to them is highly recommended.

[eophten]

#830 definitely seems related, we were also experiencing that bug. I have pulled in the changes to that file and it appears to have resolved our issue. Thanks so much for your help!