Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.After creating a new local site with drush qc --domain=xxx.dev command, the local site is fully functional until the computer power is cycled, then the url is no longer available (in Google Chrome the error reads "This webpage is not available". The "example7.dev" site that is installed with Drupalpro is always functional. Drupalpro beta2 ISO file was installed on a clean harddrive using the bootable disc process, therefore power on sequence boots directly to Drupalpro utilizing Ubuntu 12.04, not a VirtualBox.
If I add the site definitions back into the etc/hosts file, then I am able to access the sites, but after a power cycle of the computer, the file defaults back to the hosts_drupalpro file definitions. If I modify the hosts_drupalpro file to add the new sites definitions, then everything is nominal after a power cycle. So drush qc command is adding the definitions to the etc/hosts file, but it is being overwritten by the etc/hosts_drupalpro file during power on sequence.
Comments
Comment #1
highwaystar CreditAttribution: highwaystar commentedDuring either the Ubuntu 12.04 LTS power off or power on process, the "/etc/hosts" file is being overwritten. This process removes the lines referencing the newly created websites, therefore rendering them inaccessible.
Comment #2
highwaystar CreditAttribution: highwaystar commentedDoes anyone know what calls the function for the etc/hosts_drupalpro file to overwrite the etc/hosts file during power on sequence?
Comment #3
highwaystar CreditAttribution: highwaystar commentedSince the "etc/hosts_drupalpro" file was the culprit that was overwriting the required "etc/hosts" file, I decided to rename the "etc/hosts_drupalpro" file to "hosts_drupalpro_old". Now, in the absence of the "hosts_drupalpro" file the "hosts" file is no longer being overwritten and any new websites created using the drush qc --domain=foo.dev command is fully functional even after the computer is power cycled.
Although, there is probably some code in the bootup sequence of the Drupalpro Beta ISO version that could be modified, here is the process I used as a workaround to rectify this issue. Be advised this version of Drupalpro does not run in a VirtualBox, but is a direct boot utilizing Ubuntu 12.04 LTS.
Using your terminal command line interface:
1) Change to the 'root:/etc' directory (here is how I had to get there from the '/home/drupalpro' directory);
$ cd ../../etc
2) Verify correct directory and files by listing all of the files whose names start with hosts;
/etc$ ls -al hosts*
-rw-r--r-- 1 root root 440 Apr 2 21:44 hosts
-rw-r--r-- 1 root root 318 Mar 21 22:42 hosts~
-rw-r--r-- 1 root root 580 May 13 2012 hosts.allow
-rw-r--r-- 1 root root 880 May 13 2012 hosts.deny
-rw-r--r-- 1 root root 409 Mar 24 20:36 hosts_drupalpro
-rw-rw-r-- 1 root root 380 Mar 21 23:09 hosts_drupalpro~
3) Rename of the 'hosts_drupalpro' file to 'hosts_drupalpro_old' using the mv command;
/etc$ sudo mv hosts_drupalpro hosts_drupalpro_old
4) Check your file name change by re-performing the previous ls command;
/etc$ ls -al hosts*
-rw-r--r-- 1 root root 440 Apr 2 21:44 hosts
-rw-r--r-- 1 root root 318 Mar 21 22:42 hosts~
-rw-r--r-- 1 root root 580 May 13 2012 hosts.allow
-rw-r--r-- 1 root root 880 May 13 2012 hosts.deny
-rw-rw-r-- 1 root root 380 Mar 21 23:09 hosts_drupalpro~
-rw-r--r-- 1 root root 409 Mar 24 20:36 hosts_drupalpro_old
Comment #4
highwaystar CreditAttribution: highwaystar commentedPlease feel free to review this fix and/or provide any alternative code changes that would fix this issue.
Comment #5
highwaystar CreditAttribution: highwaystar commentedComment #6
pal4life CreditAttribution: pal4life commentedTest - Feel free to delete this comment
Comment #7
mike stewart CreditAttribution: mike stewart commentedsorry it's taken so long to reply, but this seems to be something custom to your environment/modifications. There is nothing in any of the setup scripts nor the contributed scripts that would create this condition.
(to verify, run this command:
grep -rin "hosts_drupalpro" ~/drupalpro/)In short, there isn't anything in drupalpro that creates or uses an /etc/hosts_drupalpro file. Drupalpro was built to be as standard/vanilla Ubuntu as possible -- and therefore uses /etc/hosts.
Unless someone can point me to code that suggests I'm incorrect, I'm going to close this issue.
@highwaystar regarding c:omment #2209031: etc/hosts file being overwritten by etc/hosts_drupalpro during power on sequence above, I appreciate your effort and dilligence trying to hunt this down and in providing feedback. I should be available in IRC or in the issue queue more frequently for at least the next few weeks if you run into other issues. That said, I'd like to provide a little feedback, in hopes to help you and anyone else new to linux/ubuntu.
#3-1 -- the
/indicates the root directory. There is no such thing as "root:/etc" .. the beginning slash explictly defines the absolute path (from the root irectory), thereforecd /etcwould be the appropriate command, and would work regardless of your working directory (found by typing:pwd). To be clear,/etc/foobaris the correct way to reference the etc directory in the root folder andetc/foobarwould be a relative path and is not explicit enough to be clear, as it may refer to a directory called etc somewhere else in the file system.#3-2 -- in Ubuntu,
/etc$ ls -al hosts*can be shortened to either:l hosts*-or-ll hosts*. This is true because Ubuntu has a predefinedalias(type alias for a complete list). other personal aliases or variable overrides (such as $PATH) should be placed in the file~/.bash_aliasesI hope this helps a little. :)
Comment #8
mike stewart CreditAttribution: mike stewart commented