taaaki

It wasn't the the hosting provider's fault since we weren't technically down for all that time. I had kept the services offline to reduce disk usage while I ensured that we had full offsite backups of everything (and having services online would also invalidate some of those backups). Getting the backups off the server took a lot longer than expected. If they had intervened and replaced the disk immediately, we likely would have lost a fair bit.

Some background on this scam: http://www.thedailyscam.com/sextortion-by-email/

I'm looking into it now. I haven't received anything on my account, so I don't have a sample mail to have a look at. This kind of blackmail message seems to be fairly common at the moment, but I've not seen one where it includes the password. The To address is usually spoofed so it's unlikely that it originated from the TDM servers - the full email headers will show where it came from. If someone is willing to share the headers of such an email with me (removing anything sensitive), I'd appreciate it. I think it's a good idea to reset your password on the forums (and wordpress if you have an account there). And maybe make a more visible notice to the forum users that there may have been a breach and that passwords should be reset. I've been planning on doing this for a while for all the services [wiki | bugs | forums | www | etc.] and I already have the certs via Let's Encrypt, but I've been neglecting the TDM admin stuff due to life things. Will see if I can at least get this done soonish. This is also important single Google will start or has already started deranking results from insecure sites.

The images thing appears to be more related to where the images are hosted. You're probably running into hotlinking (https://en.wikipedia.org/wiki/Inline_linking#Prevention) protections from PhotoBucket.

I can do some research and see if there's an easy to use off-the-shelf type catalogue and download system. Otherwise we can use the wiki as a stopgap, but that seems like it would be clumsy.

Nice find indeed. I have no issue with you committing the mktime() related changes. Once you do, I'll just need to know so that I can recompile the packager binary on the server (have to do it there since the server runs FreeBSD) and recommit the bin to SVN. I can then investigate rebuilding the differential updates and syncing to the mirrors. We might still need some process for fixing a user's existing install (for cases where there are bad PK4s from previous updates). So shouldn't we leave the timestamp altering stuff in the updater for a release or two (after fixing it for Linux)? Or do you see another way, like fixing the file reading code in TDM itself so that it doesn't get tripped up by the bad dates?

NightStalker: As you probably gleaned from the bug tracker issue, the changes to the updater were implemented as a workaround. This was because the only way to have the packager build "correct" pk4s was to force a situation where the afflicted files would have to be regenerated completely due to an "update" to an existing file and we couldn't ensure this for all the afflicted files. As I recall, this was implemented as an 11th hour kind of thing, so I admit that I probably didn't test it as well as I should have (and I don't think I got around to testing it on Linux at all) - hence the lack of issues on Windows. In theory, it shouldn't matter that the tdm_update_* files have bad dates as the cleanup step in the updater should sort this out. But it is quite likely that I may have missed something in relation to the differential updates, which would not surprise me given how difficult it is to follow the updater code (as you can attest). I'll have to try and fix my Linux environment and run some some tests on there to see if I can isolate why the cleanups didn't work (in particular, I'll need to see why the differential updates still have this issue since the packager was "fixed" prior to the release of 2.04). And I agree that this is treating the symptoms, but unless we can actually track down and properly resolve the issue in the underlying zip library (or switch to a more modern version or alternative library), I'm not sure how to finally resolve this. I assume that you also checked this bug for background: http://bugs.thedarkmod.com/view.php?id=4110 In that issue, you can see that neither gnartsch, nor myself could figure out why the dates were getting our of whack in the zip/pk4 files in the first place, but my suspicion was that the minizip library used by Doom3 is at fault. I think it might be possible to regenerate older releases, but I'll have to make sure that the packager is actually buillding valid differential update zip files. Anyway, I'll take another look at this during the week and see what I can come up with taking your suggestions into account.

I've installed some monitoring software that will send me alerts whenever it goes down, so hopefully I can get it operational a bit quicker (until I can figure out how to fix it properly at least).

Is this still happening? I tried the Full Editor in PM and didn't encounter any issues. If you are still having the issue, please specify your browser and the exact time when it occurred so that I can fish it out of the logs a bit easier.

There aren't any weightings for the mission downloader if I remember correctly. I think that it might be possible to get some debugging info for downloader, but I'll have to find the necessary cvars first...

I don't recall us changing anything to explicitly remove WinXP support. I'll see if I have a WinXP vm already so that I can test this. My personal opinion (not endorsed by TDM) is that you are doing yourself a disservice by continuing to run WinXP. With MS discontinuing support (or providing token support at best), I wouldn't trust an XP system as anything that could possibly hold or access sensitive data.

Yeah, our WordPress site was getting DoSed by around 4 IPs. I added them to the firewall blacklist, so that has relieved the pressure for now. I'm going to update the web server config to block access to the API that they were spamming, so hopefully that prevents the issue in the future.

Or not...

Should be back now.

This should work now. But I'm not sure if the way I fixed it is correct. I'll have to do some further research so expect it to break again sometime in the nearish future while I experiment. Edit: also, you may have to force a browser refresh for the forums to get the latest versions of the javascript files.

Having a look now Edit: Seems that there are some issues with IPBoard photoEditor javascript and some permission issues that I need to investigate further.

Having a look now Edit: should be fixed?

I don't think the in-game mission downloader uses weighting at all, so it just randomly picks one of the mirrors. And for missions, I think we only have 3 mirrors (2 of which are my servers). I can't remember too well, but you might be able to see which mirror is being used in the console.

It needs to extract the .so file so that it can dlopen() it [i have no idea whether or not it is possible to load a shared library from a memory stream]. However, it is a bit strange that it could find the .so file to perform the timestamp comparison, but can't find it when it needs to perform the dlopen().

The features you are looking for will depend on the IDE you choose. The choice of VS for TDM on Windows shouldn't influence your choice of IDE for Linux (as mentioned above, the build system for Linux is different, namely Scons). However, you will need to configure the build process in whichever IDE you choose so that it uses Scons to make your life a bit easier - I was lazy and just ran the scons build script in a separate terminal. Also, the build system hasn't really got much to do with the features you listed above (function locations, etc.). I was using QtCreator when I was making changes to the Linux side of TDM and that seemed to work quite well (I can't recall if it had the function/variable referencing though). You might just need to have a look through the options in CodeBlocks to enable such features or see if there are plugins that can do it for you.

To save you the hassle, I'm sure that I can setup a one-way svn2git bridge directly on the server? Might just need a bit of time.

I'm not familiar with how SVN2Github works, but I would imagine that it shouldn't be too hard to point it to the new location?

Just a heads-up to anyone using anonymous access to the TDM source code repo hosted at https://svn.thedarkmod.com/svn/darkmod_src Due to some annoying side-effects of hosting both authenticated and anonymous access to the repository via the same URL, I have decided to re-home the anonymous access URL and make the original URL always require authentication. So for anyone using anonymous access, you will need to "relocate" your working copy to https://svn.thedarkmod.com/publicsvn/darkmod_src The underlying repository is exactly the same as before, but it now uses a different URL. Assuming that your working copy points to darkmod_src/trunk, you can relocate it as follows (from your working copy directory): svn relocate https://svn.thedarkmod.com/publicsvn/darkmod_src/trunk For TortoiseSVN users, look for the relocate command and use the URL above. Apologies for any inconvenience caused. And if you experience any issues, please don't hesitate to post in this thread or drop me a PM.