There are many ways to add files to your ownCloud:
FTP Upload
SCP Upload
Local disk to ownCloud disk transfer
USB disk to ownCloud disk transfer.
But it can be pretty slow and painful process if you are adding large number of files.
Easier way is to copy the files directly to your ownCloud data directory and scan them in order to be properly added and indexed by ownCloud.
First in order to do that you need to find the “occ” command which is usually found in the root of your owncloud web directory for example /www/owncloud/occ.
Then you copy your files and folders to the data directory where your personal files are located, it could be something like /owncloud/[USERNAME]/files/.
When your files are in the new location then you need to start the scan:
Sometimes for a specific reason you want to use certain CentOS version which is removed from the main tree. Trying to update packages will report that packages for your version do not exist, but there is a way to fix this.
If you tweak the Yum repository files and remove mirrorlist directives and enable baseurl directives instead you will be able to download packages just for that specific release.
If you installed some older version of CentOS which is now moved from the main tree to the vault, you could use following script to automatically tweak all Yum repository files.
RELEASE='grep -oE '[0-9]+\.[0-9]+\.[0-9]+' /etc/centos-release'
mkdir -p /etc/yum.repos.original.d
cp -r /etc/yum.repos.d /etc/yum.repos.original.d
cd /etc/yum.repos.d
sed -i 's/^mirrorlist=/###mirrorlist=/' *
sed -i 's/^#baseurl=/baseurl=/' *
sed -i '/^baseurl/s%mirror.centos.org/centos/$releasever%vault.centos.org/$RELEASE%' *
Traditionally network device names in linux started with eth0/wlan0 where number 0 was incremented for each additional device. Problem with this naming was that device numbers did not match actual locations in computer.
Starting with v197 systemd/udev assigns predictable, stable network interface names for all local Ethernet, WLAN and WWAN interfaces. Naming is based on firmware, topology and location information.
Advantage of this approach is that the names are fully automatic, predictable and they stay fixed even if the hardware is removed or added. This allows hardware to be replaced without network cards being renamed.
Device naming is following the schemes:
o = onboard device
s = PCI hotplug
x = MAC address
P = PCI domain
p = PCI bus number
s = slot number
For example device enp0s3 would be Ethernet device in PCI bus 0 slot 3.
Ethernet device named by MAC address would start with en followed by x and MAC address (f.e. enx00112233445566).
PCI hotplug Ethernet device would start with en followed by s and the slot number, followed by f and the function number for cards that have more than one function (f.e. ens1f4).
Colection of Openstack resources that work together as three-tier application is called a stack. Stack uses openstack resources like instances, networks, volumes and objects, and other elements. The application runs on a stack.
Stack can be set-up via CLI or Horizon GUI which will send API request to various Openstack services (Keystone, Nova, Neutron, Cinder, Swift, Glance …).
Heat is the Openstack orchestration service that sends these API requests automatically. Stack description is taken by heat and interpreted to API requests. Heat accepts AWS Cloudformation templates written in JSON, but heat has it’s own native format called Heat Orchestration Template (HOT) based on YAML.
Create simple stack with heat orchestration template:
Retrieve all parameter functions supported by Openstack version:
openstack orchestration template version list
+--------------------------------------+------+
| version | type |
+--------------------------------------+------+
| AWSTemplateFormatVersion.2010-09-09 | cfn |
| HeatTemplateFormatVersion.2012-12-12 | cfn |
| heat_template_version.2013-05-23 | hot |
| heat_template_version.2014-10-16 | hot |
| heat_template_version.2015-04-30 | hot |
| heat_template_version.2015-10-15 | hot |
| heat_template_version.2016-04-08 | hot |
| heat_template_version.2016-10-14 | hot |
+--------------------------------------+------+
openstack orchestration template function list heat_template_version.2016-10-14
+-----------------+-------------------------------------------------------------------------+
| functions | description |
+-----------------+-------------------------------------------------------------------------+
| list_join | A function for joining one or more lists of strings. |
| if | A function to return corresponding value based on condition evaluation. |
| yaql | A function for executing a yaql expression. |
| digest | A function for performing digest operations. |
| get_attr | A function for resolving resource attributes. |
| repeat | A function for iterating over a list of items. |
| resource_facade | A function for retrieving data in a parent provider template. |
| map_replace | A function for performing substitutions on maps. |
| str_replace | A function for performing string substitutions. |
| get_resource | A function for resolving resource references. |
| map_merge | A function for merging maps. |
| str_split | A function for splitting delimited strings into a list. |
| get_param | A function for resolving parameter references. |
| get_file | A function for including a file inline. |
+-----------------+-------------------------------------------------------------------------+
Parameters can be provided via command line with --parameter imgname=cirros-image keyname=erol-keypair Or combine several parameters under one option: --parameter "imgname=cirros-image; keyname=erol-keypair"
If you have a lot of parameters it is probably better to put them in a file again in YAML format, with single parameters key and parameter key value pairs under that key. For example create myparameters.yaml file with following contents:
