Jump to content
The Uniform Server Community

AlleyKat

Super Moderator
  • Posts

    83
  • Joined

  • Last visited

Previous Fields

  • SourceForge ID
    dk_alleykat
  • IRC Nickname
    (@)AlleyKat :P

Contact Methods

  • Website URL
    http://phpbb2.dk
  • ICQ
    0

Profile Information

  • Location
    Odense, Denmark

Recent Profile Visitors

7,212 profile views

AlleyKat's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. As far as I can tell, the USF-variable for MySQL error log isn't used for ordinary server start/stop (if anywhere - could be used on server creation/firstrun but haven't checked). You'll have to look in the MySQL servers own .ini file - most likely my.ini - and change the error log path in there. usr\local\mysql\my.ini
  2. Nah keep posting them, it's still inspiration for the rest of us, and people getting it off this topic should know that it's a dev version. When making something slightly controversial, expect slightly controversial comments.
  3. For security reasons, a lot of devs still open the server to the world to allow (clients|customers|co-devs) access during website development. PMA is pre-setup to be open with mysql root/admin access - in my www folder I have another PMA set up with an account with limited access. Could be fixed with .htaccess of course, but to be on the safe side I think this approach is better. I'm not sure I agree completely with jacob lee, but the changes/differences are quite profound, so maybe a good idea to call it something more/else so users don't get the idea that it's a US with extra features - it's changed in more ways than one. Call it "Ota's US++" and I think we'll be on the safe side. But nice job, I like it - except for the size, ofcourse.
  4. I did wonder why there were no more. Nice job, people. Also, Merry Christmas / Fröhliche Weihnachten / Feliz Navidad / Joyeux Noël / Boas Festas / Buone Feste Natalizie to everyone.
  5. ...but I simply can't help myself when a bot posts its crap - so, I delete the topic, revoke the spammers posting rights and fixes IDs to 'spammer'. I hope that is OK - no reason to collect the spam, really.
  6. It's the new way config files should look in PMA causing this - delete the (second and third) section below the first, those with 'blank' entries. The first error you describe sounds like a small mistake was made by update of the PMA in uniserver, libraries\select_lang.lib.php needs to be fixed.
  7. Just restart the box, Apache is shut down along with all other applications on restart
  8. tim, try changing DocumentRoot /www/site2 to DocumentRoot /www/site2/
  9. You can try extracting the diskw folder contents to the root of a drive and modify start.bat and various setup files to use that - but I'm not sure its such a good idea. But maybe worth a try.
  10. Yeah, it's really weird, but maybe it's in the mailserver I'm missing something. We got everything else running - mailserver, knows it can receive, send via Outlook, run via it's own internal webmail on port 81...
  11. Sorry, your english is fine but I have no idea what you are saying...? You don't want to secure the data? OK by me. It's an offline server? Then surely noone has hacked their way into it and deleted the databases, ofcourse. If this happened due to data corruption or a fault with hardware (like hd crash) well, nothing to do. That is why one should make regular backups. If this has happened due to you for instance copying or updating/-grading the uniserver, you've most likely just started a different MySQL and your data (all databases) would then just be in another folder somewhere. As I don't quite get what you mean, I'm not sure how to help - but you could start out by searching the entire HD for folders and files named like the databases. They're stored in diskw\usr\local\mysql\data\ in the UniServer folder. It sounds highly unreasonable to me that your databases should have gone missing one by one from a running MySQL unless it's compromised somehow. It's just... unheard of.. well maybe not, but it doesn't sound very likely. Have you checked the windows logs to see if any reports were made of corruption? And the Apache logs to se if anyone from the outside hit it on port 80? To secure MySQL properly, I'll just repeat the steps: 1) Change the root account's password (and update the various related files/scripts). Or one-up it, and change the root users name too. 2) Block MySQL from accessing anything but localhost/127.0.0.1 - or block port 3306 from anything but localhost/127.0.0.1, same result. 3) As you say yourself, have each script use its own DB with own privileged-only user. And between phpMyBackupPro and the Windows Scheduler, you can even automate it...
  12. Damn, dude, you should have asked when I was online at some point... http://www.blat.net/ (Blat) http://emailrelay.sourceforge.net/ (possible other like it) I don't think it was either of these I've run across at some point, but I'm on the other hand quite sure theres a link to it here in the forums somewhere...
  13. Very, very nice site Ric, great job. Only thing I didn't quite find in there was what to change in the default US setup to have it working with mail, but that may be because no changes are needed. I'm currently trying to make US cooperate with an ArgoSoft mailserver.
  14. First of all, change the root password of MySQL. That's the safest.* Second, take regular exports of your complete database(s) or just the server - the phpMyBackupPro and phpMyAdmin easily accomplices this. Or do regular backups of the mysql folder (W:\usr\local\mysql) to be safe. * = To change it via phpMyAdmin goto PMA's front page, Privileges, look up user root, change pass. Same place you add users btw.
×
×
  • Create New...