Upgrading Magento 1.8 To 1.9.2.1 - magento-1.9

Having had the opportunity to work on a new build using Magento 2 the architecture of the application has changed significantly, to me it has definitely increased the difficulty of getting a Magento project up and running but in return offers a more granular and organised application to work with.
With this view I think it’s unlikely that you would upgrade your site to v2. Magento have not given an upgrade path to 2.0 and I doubt they will, so it’s probably worth waiting for the opportunity to re-design the site before moving over to the new platform.
Magento have committed to 3 years from general release of 2.0 so that gives you till around 2019 to move over. In the meantime that means they will continue to provide security patches and support for the 1.x platform.

Step 1- Enable maintenance mode
cd /magento_folder
#for example: cd /var/www/magento
touch maintenance.flag
Step 2: Manually you can take backup of your database and directories
Make sure you take the full backup of your store’s database and directories.
Step 3: Commence the upgrade process
cd /magento_folder
rm -rf var/cache/* var/session/*
chmod -R 777 /magento_folder
chmod 550 ./mage
./mage mage-setup .
./mage config-set preferred_state stable
./mage list-installed
#In case, modules are not listed, use the below given command to upgrade further:
./mage install http://connect20.magentocommerce.com/community Mage_All_Latest --force
#And if your Magento modules are listed – use the following commands:
./mage list-upgrades
./mage upgrade-all
#Once the upgrade process is done, you’ll see a list of modules – ‘already installed’, ’package upgraded’, make sure your permissions are set back to normal:
php shell/indexer.php reindexall
chmod -R 644 ./*
find . -type d -exec chmod 755 {} \;
chmod 550 ./mage
Step 4: Go live with your website
cd /magento_folder
rm -f maintenance.flag

Related

Remove older Hyperledger-sawtooth or pull latest repo and rerun build_all?

I had previously brought down 0.8 and want to use new version.
Is it ok to update local repo and 'build_all' or must I remove all the older docker images first?
This may be brute force, but this is what I ended up doing.
Caution, the docker command will take out all images so if you want to
preserve some of them you may want a more selective approach.
Sawtooth platform
Remove all docker images using this command docker rmi -f $(docker images -a -q)
Bring down the latest sawtooth compose file sawtooth-default.yaml
Execute compose docker-compose -f sawtooth-default.yaml up
Sawtooth repo development
Clone the latest repository
Go to the root directory of the repo cd ~\sawtooth-core
At a minimum do bin\build_all -l python
I am using java so I do a bin\build_all -l java as well
Access to individual CLI and dev languages tested out 100% as per the Hyperledger Sawtooth documentation

Install Cuda without root

I know that I can install Cuda with the following:
wget http://developer.download.nvidia.com/compute/cuda/7_0/Prod/local_installers/cuda_7.0.28_linux.run
chmod +x cuda_7.0.28_linux.run
./cuda_7.0.28_linux.run -extract=`pwd`/nvidia_installers
cd nvidia_installers
sudo ./NVIDIA-Linux-x86_64-346.46.run
sudo modprobe nvidia
sudo ./cuda-linux64-rel-7.0.28-19326674.run
Just wondering if I can install Cuda without root?
Thanks,
Update The installation UI for 10.1 changed. The following works:
Deselect driver installation (pressing ENTERon it)
Change options -> root install path to a non-sudo directory.
Press A on the line marked with a + to access advanced options. Deselect create symbolic link, and change the toolkit install path.
Now installation should work without root permissions
Thank you very much for the hints in the question! I just want to complete it with an approach that worked for me, also inspired in this gist and that hopefully helps in situations where a valid driver is installed, and installing a more recent CUDA on Linux without root permissions is still needed.
TL;DR: Here are the steps to install CUDA9+CUDNN7 on Debian, and installing a pre-compiled version of TensorFlow1.4 on Python2.7 to test that everything works. Everything without root privileges and via terminal. Should also work for other CUDA, CUDNN, TensorFlow and Python versions on other Linux systems too.
INSTALLATION
Go to NVIDIA's official release web for CUDA (as for Nov. 2017, CUDA9 is out): https://developer.nvidia.com/cuda-downloads.
Under your Linux distro, select the runfile (local)option. Note that the sudo indication present in the installation instructions is deceiving, since it is possible to run this installer without root permissions. On a server, one easy way is to copy the <LINK> of the Download button and, in any location of your home directory, run wget <LINK>. It will download the <INSTALLER> file.
Run chmod +x <INSTALLER> to make it executable, and execute it ./<INSTALLER>.
accept the EULA, say no to driver installation, and enter a <CUDA> location under your home directory to install the toolkit and a <CUDASAMPLES> for the samples.
Not asked here but recommended: Download a compatible CUDNN file from the official web (you need to sign in). In my case, I downloaded the cudnn-9.0-linux-x64-v7.tgz, compatible with CUDA9 into the <CUDNN> folder. Uncompress it: tar -xzvf ....
Optional: compile the samples. cd <CUDASAMPLES> && make. There are some very nice examples there and a very good starting point to write some CUDA scripts of yourself.
(If you did 5.): Copy the required files from <CUDNN> into <CUDA>, and grant reading permission to user (not sure if needed):
cp -P <CUDNN>/cuda/include/cudnn.h <CUDA>/include/
cp -P <CUDNN>/cuda/lib64/libcudnn* <CUDA>/lib64
chmod a+r <CUDA>/include/cudnn.h <CUDA>/lib64/libcudnn*
Add the library to your environment. This is typically done adding this following two lines to your ~/.bashrc file (in this example, the <CUDA> directory was ~/cuda9/:
export PATH=<CUDA>/bin:$PATH
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:<CUDA>/lib64/
FOR QUICK TESTING OR TENSORFLOW USERS
The quickest way to get a TensorFlow compatible with CUDA9 and CUDNN7 (and a very quick way to test this) is to download a precompiled wheel file and install it with pip install <WHEEL>. Most of the versions you need, can be found in mind's repo (thanks a lot guys). A minimal test that confirms that CUDNN is also working involves the use of tf.nn.conv2d:
import tensorflow as tf
x = tf.nn.conv2d(tf.ones([1,1,10,1]), tf.ones([1,5,1,1]), strides=[1, 1, 1, 1], padding='SAME')
with tf.Session() as sess:
sess.run(x) # this should output a tensor of shape (1,1,10,1) with [3,4,5,5,5,5,5,5,4,3]
In my case, the wheel I installed required Intel's MKL library, as explained here. Again, from terminal and without root users, this are the steps I followed to install the library and make TensorFlow find it (reference):
git clone https://github.com/01org/mkl-dnn.git
cd mkl-dnn/scripts && ./prepare_mkl.sh && cd ..
mkdir -p build && cd build
cmake -D CMAKE_INSTALL_PREFIX:PATH=<TARGET_DIR_IN_HOME> ..
make # this takes a while
make doc # do this optionally if you have doxygen
make test # also takes a while
make install # installs into <TARGET_DIR_IN_HOME>
add the following to your ~/.bashrc: export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:<TARGET_DIR_IN_HOME>/lib
Hope this helps!
Andres
You can install using conda with the following command.
conda install -c anaconda cudatoolkit
But you need to have prior accesss to the device(GPU).
EDIT : If you are finding error in anaconda repository then change the repository to conda-forge which is frequently updated.
conda install -c conda-forge cudatoolkit
You can install CUDA and compile programs, but you won't be able to run them for a lack of device access.

how to build grub2 bootloader from it's source and test it with qemu emulator

I want to know how to build grub 2 bootloader from it's source in ubuntu and test it with qemu emulator.
I would also like to change the default background image of grub2 bootloader in the new build?
Is this possible? If yes, how ?
Of course you can.
As shown on the GRUB website, the grub source code is available via git from git.savannah.gnu.org.
Then it is theoretically just a question of
$ ./autogen.sh
$ ./configure
$ make
$ sudo make install
However, depending on your platform, grub's default target platform may or may not be what you want. So you will need to decide which firmware platform you want to use in QEMU, which depending on your architecture can be something like
(pc) BIOS
coreboot
(U)EFI
ieee1275 (open firmware)
u-boot
Your mentioning of Ubuntu matches at least 3 possible options from the above, but I'm going to be boring and assume you mean x86_64/amd64. Since you will be running GRUB under QEMU, it does not really matter which of the two likely platforms ("pc" or "efi") your physical computer is running. So let's live a little and go for the (U)EFI variant.
You will need some prerequisites installed before configuring and building, so
$ sudo apt-get install build-essential autoconf automake
$ sudo apt-get build-dep grub-efi-amd64
So a practical build may look a bit like this:
$ # Next command is optionnal (languages):
$ ./linguas.sh
$ ./autogen.sh
$ # Next parameters are optionnal:
$ ./configure --prefix=$HOME/local --platform=efi
$ make
$ # Next command is optionnal:
$ make check
$ make install
The easiest way to get a functioning GRUB image is probably with the grub-mkstandalone command:
$ $HOME/local/bin/grub-mkstandalone -O x86_64-efi -o mygrub.efi
Note: To install grub on /dev/sda disk (instead of QEMU), use:
$ sudo grub-install /dev/sda
Note: If you don't see GRUB menu when booting, check this question. It involves pressing Shift when booting or editing /etc/default/grub to comment GRUB_HIDDEN_TIMEOUT.
Then you need some kind of UEFI image to run under your QEMU. The default choice for x86 is called OVMF and is part of Tianocore EDK2 - the de facto open source implementation of UEFI. Due to legal technicalities with regards to redistribution of the FAT filesystem driver, many Linux distributions (including Ubuntu) do not include a pre-built one. But have no fear, it is pretty straightforward to build one yourself.
However, I am not going to take this answer further off-topic than I already have, so all I am going to say is have a read through the OVMF README and look through one or two only slightly outdated blog posts about it.

kubernetes installation on coreOS

I am setting up Kubernetes on coreOS, on GCE. However, it is not going through due to the SDK dependency on Python. I downloaded python and tried installing it, but it is looking for a C compiler. Unfortunately I couldn't get one. Could someone help with this?
Below is the link I am following to set this up
https://github.com/rimusz/coreos-multi-node-k8s-gce/blob/master/README.md
You're probably better off using a cloud-init file that curls, installs and runs each binary for kubernetes as a systemd unit. So each would look like:
- name: kube-apiserver.service
command: start
content: |
[Unit]
Description=Kubernetes API Server
Documentation=https://github.com/GoogleCloudPlatform/kubernetes
Requires=etcd2.service setup-network-environment.service
After=etcd2.service setup-network-environment.service
[Service]
EnvironmentFile=/etc/network-environment
ExecStartPre=-/usr/bin/mkdir -p /opt/bin
ExecStartPre=/usr/bin/curl -L -o /opt/bin/kube-apiserver -z /opt/bin/kube-apiserver https://storage.googleapis.com/kubernetes-release/release/v0.18.2/bin/linux/amd64/kube-apiserver
ExecStartPre=/usr/bin/chmod +x /opt/bin/kube-apiserver
ExecStartPre=/usr/bin/curl -L -o /opt/bin/kubectl -z /opt/bin/kubectl https://storage.googleapis.com/kubernetes-release/release/v0.18.2/bin/linux/amd64/kubectl
ExecStartPre=/usr/bin/chmod 755 /opt/bin/kubectl
ExecStart=/opt/bin/kube-apiserver --portal_net=10.244.0.0/16 --etcd_servers=http://127.0.0.1:4001 --logtostderr=true --insecure_port=8080 --insecure_bind_address=0.0.0.0
Restart=always
RestartSec=10
And similar for each other binary. Just make sure you set them up to follow the chain of dependencies. This way the binaries are already compiled, compiling is something that coreos isn't exactly designed for.

Alternative ways to deploy code to Openshift

I am trying to setup Travis CI to deploy my repository to Openshift on a successful build. Is there a way to deploy a repository besides using Git?
Git is the official mechanism for how your code is update, however depending on the type of application that you are deploying you may not need to deploy your entire code base.
For example Java application (war, ear, etc) can be deployed to JBoss or Tomcat servers, by simply taking the built application and checking it into the OpenShift git repositories, webapps or deploy directories.
An alternative to this (and it will be unsupported), is to scp your application to the gear using the SSH key. However any time the application is moved or updated (with git) this content stands a good chance of getting deleted(cleaned), by the gear.
We're working on direct binary deploys ("push") and "pull" style deploys (Openshift downloads a binary for you. The design/process is described here:
https://github.com/openshift/openshift-pep/blob/master/openshift-pep-006-deploy.md
You can do a SCP to the app-root/dependencies/jbossews/webapps directory direcly. I was able to do that successfully and have the app working. Here is the link
Here is the code which I had in the after_success blck
after_success:
- sudo apt-get -y install sshpass
- openssl aes-256-cbc -K $encrypted_8544f7cb7a3c_key -iv $encrypted_8544f7cb7a3c_iv
-in id_rsa.enc -out ~/id_rsa_dpl -d
- chmod 600 ~/id_rsa_dpl
- sshpass scp -i ~/id_rsa_dpl webapps/ROOT.war $DEPLOY_HOST:$DEPLOY_PATH
Hope this helps