![]() The two settings that Emma provides is what you need to focus on, Andy. Also, be careful preserving your config.php file. But if you have changed code, you need to think about the update. For example, if you customize a theme using the themes custom CSS textbox, you are fine. The answer to this question depends upon what kind of customization you have done. Yes, be careful over writing custom files. It is the first link on this one webpage of mine. I made this video to show how I do some of this on one of my Godaddy hosted servers. When you make it through all of this, you will have learned a lot. With time, clone you production moodle data. The concept is as follows:ġ) Create a new database, call it something like moodle3exp.Ģ) Create a new moodledata folder, call it something like moodledata3exp.ģ) Install a new copy of moodle into its own folder, call it something like /moodle3exp.ĭo the install. What you can do is install another copy of Moodle for experimenting in the main domain. Remove the log from your own eye before picking at the straw in someone else's.Andy, there is no need to clone the site as a subdomain, although one can. People who publicly criticise hosts for storing passwords in clear, but then use the same password for multiple services, are nothing less than hypocrites. Your process of keeping your credentials secure should not depend on the security practices at any single one of the services you use. Whilst I agree that storing cleartext passwords is not a great idea, I think the worse idea is to rely on every single web service you belong to to keep your authentication/authorisation credentials secure. The list can be stolen or misused, and this sort of thing happens routinely. Still, storing recoverable passwords (which is what most people mean when they say "cleartext") without clear notice is a terrible idea for all the reasons people expect. Just reset the ssh keys and bounce it ("oops, power failure!"), or just read out the data from your logs via a snapshot of the partitions, etc.ĭefinitely, which is why, as others have pointed out, you have to get a host you can trust. ![]() It's also worth noting that, because they control the storage for your hosted server, they can access it without your permission whether you want to allow them to or not. They could either commercially exploit them or hold my business for ransom. (Change MX record to point from Google Apps to 元3t Hacker Krue, ask for password reset, watch as Internet obligingly delivers the email straight to their server.)ģ) My real nightmare: authorize transfer of my domains from my account at GoDaddy to their account at a disreputable registrar. ![]() So that they can compromise anything attached to my email address(es) without ever having to actually compromise my email provider. It would allow an attacker to:ġ) Compromise my DNS settings. ![]() That scares me because the prospect of a compromise of my GoDaddy account is really bad. However, if their customer service reps can try his GoDaddy account passwords to attempt to log into his VPS, that means that GoDaddy is holding those in the clear somewhere, and that makes it very, very likely they are holding my passwords in the clear, too. As 'regularfry ably pointed out, you gave up your root password when you opted for a VPS.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |