I have looked through the answers and I am not sure which will work for me , so I am writing the question again, Hoping for a response that might work.
Here : http://norstore-trd-bio0.hpc.ntnu.no/tfcp/
I have a database on server and I am using Joomla to create the website and manage database.
This was a test version, now I want to have the database here it self but use the new URL for website http://tfcheckpoint.org/ bought by godaddy.com.
According to godaddy i tried to first mask the website that is kinda a redirect tfcheckpoint.org to orginal site as explained here:
http://support.godaddy.com/help/article/422/forwarding-or-masking-your-domain-name
BUT, this cause some links to be broken and not accessible anymore, since the external URL is fixed.
Secondly I looked for other solutions and tried to get the mysql dump and replace the old url with new url everywhere and imported the sql file again, but nothing changed. probably because the new site is masked and I have to unmask it. Or should I install Joomla again and start from scratch with the new URL.
But is there a proper way to do this. I don't think moving the database to new hosting server is the solution as many people have their data on local servers while they use these fancy domain names.
Please guide me if there is a standard procedure to do so.
As far as I can tell from your question, you are merely trying to move a Joomla site from one hoster's server to another? You may even be moving between hosters...my answer still stands.
Firstly I have heard of many issues with GoDaddy for Joomla sites. But that is probably an answer for a different question.
In terms of moving your test site and "turning" it into a live site on a new server, this can be done with a 3rd party tool like Akeeba Backup.
For Joomla's settings in the new location, you will need to change the details to accommodate the new hoster's details for database and file locations. This is done through the Site Restoration process(made very easy in Akeeba). There is also a setting for LiveSite that you have have set which would need to be changed manually in /newlocation ofyour files/joomla install/configuration.php.
In terms of DNS settings, your new domain should point to the new hoster's server and a 301 redirect against the old domain pointing to the new one should cover all the bases.
I hope that answers your question. If not, I suggest rewriting the question to be more clear. You will probably get more answers
Related
I was just hired to maintain and redesign various site the company has running on an old version of DNN. The site has been hacked and someone uploaded some directories and web.config files that were redirecting users to stream suspicious streaming sites. Also, the attacker added some scripts that show Google Ads on all the blog articles. Needless to say its a mess.
Nevertheless, I was able to go in there, deleted a super admin account (that's how they got in I think) , delete a few directories that had over a thousand html files for streaming sites and also deleted the old FCK Editor.
I am completely new to DNN and need some help with the directory and structure to try and see if I can resolve this. So far, I cannot get rid of the Google Ads in the blog and for the life of me I cannot find where the blog articles live inside the root/directory. When I go in there and delete the ads through the DNN UI the ads come back in hours or a couple of days. The directories with the html files have not returned. Just the ads.
I know that we have to upgrade but if I remove the ads I will have more to to develop the new sites without feeling rushed because of the current issue.
If anyone can point me in the right direction I would really appreciate it.
That sounds awful, as obviously someone (ore something) still manipulates your site from the outside (or inside?). There are a lot of issues on old DNN Versions, and the only thing I can really recommend is to find an upgrade path to the newest version. I don't know how big your site is, maybe it is easier to set it up from scratch with a new version (if the site is not too big).
The directory structure does not help you finding any content as everything is stored in a database. To be more specific I would need more information about the DNN version and the extensions (and versions of the extensions) in use, but disclosing this here in the public could be a security risk for you. You could write me a PM here if you wish to get in contact.
To find people (maybe in your area) who can help you could give these web sites a try: https://dnncommunity.org (Resources > Forums) and https://dodnn.work/.
It sounds like your site might have been impacted by a few different exploits, and most likely I would guess it is version 7.x or earlier and been upgraded from versions prior to that.
For the immediate need you are going to need to try and identify anything and everything that is out of the norm, this can be very daunting for those that are not familiar with the platform, but a few tips.
Look in the DB for data in the Header or Footer field of the TabModules table
Look for any rogue files that really should not be there, anything with an extension of (.php, .asp, etc.)
Look for rogue files in directories outside of the /Portals/* folder that don't match a DNN Install. (This takes a bit of personal experience.)
Look at your default.aspx file it should NOT have a recent modified date. If it does, compare it against the one that you get when you download the install package of that version of DNN
Now, once you have done this, be sure to do any mitigations that you can for known exploits. Including:
Delete /Install/Install.aspx
Delete /Install/InstallWizard.aspx
Disable any host account with a username of 'host' and create a new one if that was your only one
Feel free to email me directly as well if you need some help.
I currently have a website i'm working on that I have taken over from another individual, I dumped his SQL file into my database and everything seems to be ok apart from one thing. Whenever I try to log in to the back end or if I try to go elsewhere, it will add an additional .co.uk to the address bar, making it like so:
From: www.domain.co.uk to www.domain.co.uk.co.uk
I've had a dig in the database but I really can't find anything and i've never faced this issue before, could anyone shed some light on this for me? Maybe just let me know where I could look within the database to identify the problem, many thanks.
Take a look at the .htaccess file in the root folder, which is hidden and may contain rewrite rules.
Also, I recommend you use this plugin for migrations:
http://wordpress.org/extend/plugins/wp-migrate-db/
I use it whenever I move from localhost to a live site and vice versa. It will also ensure your widgets are preserved, since doing a find replace will cause the object serialisation syntax WordPress uses to break.
After migrating, you need to visit Settings > Permalinks so the .htaccess file can be updated according to the new URL for rewrites.
OK, so I did the dumb thing and released production code (C#, VS2010) that targeted our development database (SQL Server 2008 R2). Luckily we are not using the production database yet so I didn't have the pain of trying to recover and synchronize everything...
But, I want to prevent this from happening again when it could be much more painful. My idea is to add a table I can query at startup and determine what database I am connected to by the value returned. Production would return "PROD" and dev and test would return other values, for example.
If it makes any difference, the application talks to a WCF service to access the database so I have endpoints in the config file, not actual connection strings.
Does this make sense? How have others addressed this problem?
Thanks,
Dave
The easiest way to solve this is to not have access to production accounts. Those are stored in the Machine.config file for our .net applications. In non-.net applications this is easily duplicated, by having a config file in a common location, or (dare I say) a registry entry which holds the account information.
Most of our servers are accessed through aliases too, so no one really needs to change the connection string from environment to environment. Just grab the user from the config and the server alias in the hosts file points you to the correct server. This also removes the headache from us having to update all our config files when we switch db instances (change hardware etc.)
So even with the click once deployment and the end points. You can publish the a new endpoint URI in a machine config on the end users desktop (I'm assuming this is an internal application), and then reference that in the code.
If you absolutely can't do this, as this might be a lot of work (last place I worked had 2000 call center people, so this push was a lot more difficult, but still possible). You can always have an automated build server setup which modifies the app.config file for you as a last step of building the application for you. You then ALWAYS publish the compiled code from the automated build server. Never have the change in the app.config for something like this be a manual step in the developer's process. This will always lead to problems at some point.
Now if none of this works, your final option (done this one too), which I hated, but it worked is to look up the value off of a mapped drive. Essentially, everyone in the company has a mapped drive to say R:. This is where you have your production configuration files etc. The prod account people map to one drive location with the production values, and the devs etc. map to another with the development values. I hate this option compared to the others, but it works, and it can save you in a pinch with others become tedious and difficult (due to say office politics, setting up a build server etc.).
I'm assuming your production server has a different name than your development server, so you could simply SELECT ##SERVERNAME AS ServerName.
Not sure if this answer helps you in a assumed .net environment, but within a *nix/PHP environment, this is how I handle the same situation.
OK, so I did the dumb thing and released production code
There are a times where some app behavior is environment dependent, as you eluded to. In order to provide this ability to check between development and production environments I added the following line to global /etc/profile/profile.d/custom.sh config (CentOS):
SERVICE_ENV=dev
And in code I have a wrapper method which will grab an environment variable based on name and localize it's value making it accessible to my application code. Below is a snippet demonstrating how to check the current environment and react accordingly (in PHP):
public function __call($method, $params)
{
// Reduce chatter on production envs
// Only display debug messages if override told us to
if (($method === 'debug') &&
(CoreLib_Api_Environment_Package::getValue(CoreLib_Api_Environment::VAR_LABEL_SERVICE) === CoreLib_Api_Environment::PROD) &&
(!in_array(CoreLib_Api_Log::DEBUG_ON_PROD_OVERRIDE, $params))) {
return;
}
}
Remember, you don't want to pepper your application logic with environment checks, save for a few extreme use cases as demonstrated with snippet. Rather you should be controlling access to your production databases using DNS. For example, within your development environment the following db hostname mydatabase-db would resolve to a local server instead of your actual production server. And when you push your code to the production environment, your DNS will correctly resolve the hostname, so your code should "just work" without any environment checks.
After hours of wading through textbooks and tutorials on MSBuild and app.config manipulation, I stumbled across something called SlowCheetah - XML Transforms http://visualstudiogallery.msdn.microsoft.com/69023d00-a4f9-4a34-a6cd-7e854ba318b5 that did what I needed it to do in less than hour after first stumbling across it. Definitely recommended! From the article:
This package enables you to transform your app.config or any other XML file based on the build configuration. It also adds additional tooling to help you create XML transforms.
This package is created by Sayed Ibrahim Hashimi, Chuck England and Bill Heibert, the same Hashimi who authored THE book on MSBuild. If you're looking for a simple ubiquitous way to transform your app.config, web.config or any other XML fie based on the build configuration, look no further -- this VS package will do the job.
Yeah I know I answered my own question but I already gave points to the answer that eventually pointed me to the real answer. Now I need to go back and edit the question based on my new understanding of the problem...
Dave
I' assuming yout production serveur has a different ip address. You can simply use
SELECT CONNECTIONPROPERTY('local_net_address') AS local_net_address
Has anyone made any headway with coming up with a single sign on solution
with Domain access to date for Drupal 7? I've been looking closely at two old
modules, one no longer maintained (SSO for D6) and one still maintained (CAS). I've also read that SAML might be a key to unlocking this, but am uncertain.
Facebook's FBConnect might be another option too or another way could be integrating OpenID from what I've read, and experienced on StackOverflow's sub sites.
I know that OpenID can do this since we are logged into all of *Overflows sub sites at the same time using one login. The question is how does it cross DNS servers? Does it handshake with one half of a matching hash? I cannot find any documentation on this, so am at a loss.
So, are there any solutions that are known to date, or information on what to start
looking into? I think I've made a good point at the possibilities. I read this thread, Domain Access SSO but am uncertain to what version it pertains to (Drupal. DA, SSO or otherwise). It looks like the "Solution" is to create a master table set with users and permissions, then share those across the domains? How might this work if there are already multiple sites created under Domain Access? Would you clone and rebuild the entire installation, or would you need to start from scratch? It really raises more questions than answers. I contacted the author with no response, so the questions still stand.
Any opinions out there on the who what or why would be greatly appreciated, I just need a start point to get the ball rolling. Thanks everyone.
I'm the author of the Domain Access SSO article mentioned in the original question. I don't recall being contacted about it, but then again I recently learned that my "contact" page on bleen.net hasn't been working in a while... but anyway, here is a bit of info:
That post referred to Drupal 6, SSO Module 6.x-1.0-rc1, and Domain Access module 6.x-2.0 (I think). That solution basically revolves around creating two separate drupal installs, one the master and one the client (there can be multiple clients). Basically, what happens is the necessary user tables for all teh clients are pointed instead to the master. In doing so, the master becomes (essentially) a shell site that does nothing but hold and verify user data.
Hope that makes sense and/or helps... to be honest i havent looked at that code in a long while now.
SAML is a good option. Check this module to integrate it with drupal:
http://drupal.org/project/simplesamlphp_auth
If you need a demo with this plugin working check this.
I ran across a new problem in the last week. Due to the nature of my project and available budget a small intranet web application I've been working on is both the testing and live server, as well as serves up the pages and is the sql server. This will last at least until the project is out of the major development cycle. Now that the project has real users but I am continuing development I duplicated the database to have a safe copy to mess with that won't cause havoc to live business data and a development copy of the website.
All was well until I discovered an anomoly on the test copy of the site, anything that uses a sql datasource was properly pulling it's data from the test database, but anything that gets it's data from a stored procedure triggered in the code behind was pulling it's data from the live databse.
My confusion comes from the fact that all stored procedures and sql datasources ultimately point back to the same connectionstring setting in the web.config file to know where to connect to. I just rename the database name depending on if I'm uploading the latest changes to the test or live site.
My question comes down to, why would with one connection string in each site would my test site accessing data one way get it from one database and accessing the other get it's data from the other database?
Here's my connection string they all point back to, names/passwords of course change for obvious reasons, but the structure is intact.
<add name="db_Connection" connectionString="Data Source=SERVERNAME;Initial Catalog=DATABASE_live;Persist Security Info=False;User ID=USERID;Password=password" providerName="System.Data.SqlClient"/>
I added a key to the appsettings to reference the name of the database connection so I could easily change it's name if need be without having to edit dozens of pages for the code behind SProc calls.
<add key="defaultDB" value="db_Connection" />
Am I violating some rule I'm unaware of or is there something else going on that I need to be aware of and change so I can have a true test environment as I continue to develop an active site?
EDIT This project is in ASP.NET 2.0 VB, fixed the code display.
solution found I have tracked down the solution, thanks for the pointers, they got me looking elsewhere. When I copied the site to a different location for testing I forgot to update my appsetting key for the site's location, this caused the following part of the call for stored procedures to grab data from the live site's web.config aparently.
System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration(pubvar_webConfig)
Change the username and password on the dev database. If your problem persists then you might have a connection string set somewhere else that you don't know about.
I would search all of the files in your solution to make sure you don't have one of the database names hard coded some place. Maybe in the designer files?
It may be worth running the two applications in different app pools via IIS (if you aren't already or course!). This should eliminate any concurrency issues between the test and production sites at the application level.
IMHO with a shared test / production environment seperate app pools is good practice at any time.