Re: [jira] [Commented] (CLOUDSTACK-10025) To create a better VNC client for Cloudstack using noVNC

[Mohammad Aladwan]

hi,

please i want to leave this group,i am not sure how i  can leave it


my best regards

On Mon, Dec 11, 2017 at 1:55 AM, ASF GitHub Bot (JIRA) 
wrote:

>
> [ https://issues.apache.org/jira/browse/CLOUDSTACK-10025?
> page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&
> focusedCommentId=16285617#comment-16285617 ]
>
> ASF GitHub Bot commented on CLOUDSTACK-10025:
> -
>
> sachinnitw1317 commented on issue #2204: [CLOUDSTACK-10025] Adding Support
> for NoVNC Console for KVM and XENSERVER
> URL: https://github.com/apache/cloudstack/pull/2204#issuecomment-350647294
>
>
>Hey, I reported the keyboard problem earlier as well. If you do a right
> click -> reload frame it will start taking your keyboard strokes. I never
> got the fix though. Let me  know if you need any help from me.
>
> 
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on GitHub and use the
> URL above to go to the specific comment.
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
>
>
> > To create a better VNC client for Cloudstack using noVNC
> > 
> >
> > Key: CLOUDSTACK-10025
> > URL: https://issues.apache.org/
> jira/browse/CLOUDSTACK-10025
> > Project: CloudStack
> >  Issue Type: New Feature
> >  Security Level: Public(Anyone can view this level - this is the
> default.)
> >  Components: VNC Proxy
> >Affects Versions: 4.11.0.0
> >Reporter: Sachin
> >Priority: Minor
> >  Labels: features
> >
> > I have implemented this feature as my GSoC'17 project. noVNC is written
> in javascript and uses websockets to connect to VNC server. We have
> modified the ConsoleProxy server to accept websocket request from noVNC
> client, which then forwards the request request to VNC server.
> > Javascript cannot make plain tcp request, hence the websocket request
> have to be forwarded to the VNC server via a proxy server that basically
> converts websocket request from client to plain tcp request for VNC server.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.14#64029)
>

Re: [GitHub] sachinnitw1317 commented on issue #2204: [CLOUDSTACK-10025] Adding Support for NoVNC Console for KVM and XENSERVER

[Mohammad Aladwan]

hi,

please i want to leave this group,i am not sure how i  can leave it


my best regards

On Mon, Dec 11, 2017 at 1:54 AM, GitBox  wrote:

> sachinnitw1317 commented on issue #2204: [CLOUDSTACK-10025] Adding Support
> for NoVNC Console for KVM and XENSERVER
> URL: https://github.com/apache/cloudstack/pull/2204#issuecomment-350647294
>
>
>Hey, I reported the keyboard problem earlier as well. If you do a right
> click -> reload frame it will start taking your keyboard strokes. I never
> got the fix though. Let me  know if you need any help from me.
>
> 
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on GitHub and use the
> URL above to go to the specific comment.
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
>
>
> With regards,
> Apache Git Services
>

Re: [GitHub] rhtyd closed pull request #2214: Speed-up VR initialisation/configuration

[Mohammad Aladwan]

hi,

please i want to leave this group,i am not sure how i  can leave it


my best regards

On Sun, Dec 10, 2017 at 4:07 PM, GitBox  wrote:

> rhtyd closed pull request #2214: Speed-up VR initialisation/configuration
> URL: https://github.com/apache/cloudstack/pull/2214
>
>
>
>
> This is a PR merged from a forked repository.
> As GitHub hides the original diff on merge, it is displayed below for
> the sake of provenance:
>
> As this is a foreign pull request (from a fork), the diff is supplied
> below (as it won't show otherwise due to GitHub magic):
>
> diff --git a/systemvm/patches/debian/buildsystemvm.sh
> b/systemvm/patches/debian/buildsystemvm.sh
> index a34b1dd0a61..f8726439925 100755
> --- a/systemvm/patches/debian/buildsystemvm.sh
> +++ b/systemvm/patches/debian/buildsystemvm.sh
> @@ -228,7 +228,7 @@ cat > etc/init.d/iptables-persistent << EOF
>  #!/bin/sh
>  ### BEGIN INIT INFO
>  # Provides:  iptables
> -# Required-Start:mountkernfs $local_fs
> +# Required-Start:mountkernfs $local_fs cloud-early-init
>  # Required-Stop: $local_fs
>  # Should-Start:  cloud-early-config
>  # Default-Start: S
> @@ -418,6 +418,8 @@ services() {
>
>/bin/cp -r ${scriptdir}/config/* ./
>chroot . chkconfig xl2tpd off
> +  chroot . chkconfig --add cloud-early-init
> +  chroot . chkconfig cloud-early-init on
>chroot . chkconfig --add cloud-early-config
>chroot . chkconfig cloud-early-config on
>chroot . chkconfig --add iptables-persistent
> diff --git a/systemvm/patches/debian/config/etc/init.d/cloud
> b/systemvm/patches/debian/config/etc/init.d/cloud
> index f9a9915223e..47dd47b74da 100755
> --- a/systemvm/patches/debian/config/etc/init.d/cloud
> +++ b/systemvm/patches/debian/config/etc/init.d/cloud
> @@ -1,11 +1,11 @@
> -#!/bin/bash
> +#!/bin/bash
>  ### BEGIN INIT INFO
>  # Provides:  cloud
> -# Required-Start:mountkernfs $local_fs cloud-early-config
> +# Required-Start:mountkernfs $local_fs cloud-early-init
>  # Required-Stop: $local_fs
> -# Should-Start:
> -# Should-Stop:
> -# Default-Start:
> +# Should-Start:
> +# Should-Stop:
> +# Default-Start:
>  # Default-Stop:  0 1 6
>  # Short-Description:   Start up the CloudStack cloud service
>  ### END INIT INFO
> @@ -44,7 +44,7 @@ for i in $CMDLINE
>do
>  # search for foo=bar pattern and cut out foo
>  FIRSTPATTERN=$(echo $i | cut -d= -f1)
> -case $FIRSTPATTERN in
> +case $FIRSTPATTERN in
>type)
>TYPE=$(echo $i | cut -d= -f2)
>;;
> @@ -104,7 +104,7 @@ start() {
>   then
> (cd $CLOUDSTACK_HOME/systemvm; nohup ./run.sh > $LOG_FILE 2>&1 & )
> pid=$(get_pids)
> -   echo $pid > /var/run/cloud.pid
> +   echo $pid > /var/run/cloud.pid
>   fi
>   _success
> else
> @@ -137,7 +137,7 @@ status() {
>return 0
>  }
>
> -[ "$ENABLED" != 0 ] || exit 0
> +[ "$ENABLED" != 0 ] || exit 0
>
>  case "$1" in
> start) start
> diff --git a/systemvm/patches/debian/config/etc/init.d/cloud-early-config
> b/systemvm/patches/debian/config/etc/init.d/cloud-early-config
> index 3bdebdbb798..cfbdd90f1cb 100755
> --- a/systemvm/patches/debian/config/etc/init.d/cloud-early-config
> +++ b/systemvm/patches/debian/config/etc/init.d/cloud-early-config
> @@ -1,10 +1,10 @@
>  #!/bin/bash
>  ### BEGIN INIT INFO
>  # Provides:  cloud-early-config
> -# Required-Start:mountkernfs $local_fs
> -# Required-Stop: $local_fs
> -# Should-Start:
> -# Should-Stop:
> +# Required-Start:mountkernfs $local_fs cloud-early-init
> +# Required-Stop: $local_fs cloud-early-init
> +# Should-Start:
> +# Should-Stop:
>  # Default-Start: S
>  # Default-Stop:  0 6
>  # Short-Description: configure according to cmdline
> @@ -43,7 +43,7 @@ rm -f /var/cache/cloud/boot_up_done
>  . /lib/lsb/init-functions
>
>  log_it() {
> -  echo "$(date) $@" >> /var/log/cloud.log
> +  echo "$(date) cloud-early-config $@" >> /var/log/cloud.log
>log_action_msg "$@"
>  }
>
> @@ -52,11 +52,11 @@ init_interfaces_orderby_macs() {
>  total_nics=${#macs[@]}
>  interface_file=${2:-"/etc/network/interfaces"}
>  rule_file=${3:-"/etc/udev/rules.d/70-persistent-net.rules"}
> -
> +
>  echo -n "auto lo" > $interface_file
>  for((i=0; i  do
> -if [[ $i < 3 ]]
> +if [[ $i < 3 ]]
>  then
> echo -n " eth$i" >> $interface_file
>  fi
> @@ -70,7 +70,7 @@ EOF
>  echo "" > $rule_file
>  for((i=0; i < ${#macs[@]}; i++))
>  do
> -echo "SUBSYSTEM==\"net\", ACTION==\"add\", DRIVERS==\"?*\",
> ATTR{address}==\"${macs[$i]}\", NAME=\"eth$i\"" >> $rule_file
> +echo "SUBSYSTEM==\"net\", ACTION==\"add\", DRIVERS==\"?*\",
> ATTR{address}==\"${macs[$i]}\", NAME=\"eth$i\"" >> $rule_file
>  done
>  }
>
> @@ -151,7 +151,7 @@ get_boot_params() {
>chmod go-rwx /root/.ssh/authorized_keys
>;;
>   vmware)
> -  vmtoolsd --cmd 

Re: [DISCUSS] Replace the default built-in centos template

[Mohammad Aladwan]

hi,

please i want to leave this group,i am not sure how i  can leave it


my best regards

On Sat, Dec 9, 2017 at 8:36 AM, Rohit Yadav 
wrote:

> All,
>
> I would like to kick a discussion thread on replacing the current centos5
> based built-in guest vm template with a systemd and cloud-init enabled
> centos7 one?
>
> Thoughts, comments?
>
> Regards.
>
> Get Outlook for Android
>
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>

Re: [GitHub] blueorangutan commented on issue #2211: CLOUDSTACK-10013: Migrate systemvmtemplate to Debian9

[Mohammad Aladwan]

hi,

please i want to leave this group,i am not sure how i  can leave it


my best regards

On Fri, Dec 8, 2017 at 4:58 AM, GitBox  wrote:

> blueorangutan commented on issue #2211: CLOUDSTACK-10013: Migrate
> systemvmtemplate to Debian9
> URL: https://github.com/apache/cloudstack/pull/2211#issuecomment-349729490
>
>
>Trillian test result (tid-1736)
>Environment: vmware-55u3 (x2), Advanced Networking with Mgmt server 7
>Total time taken: 99133 seconds
>Marvin logs: https://github.com/blueorangutan/acs-prs/
> releases/download/trillian/pr2211-t1736-vmware-55u3.zip
>Test /marvin/tests/smoke/test_accounts.py took 2221 seconds
>Test /marvin/tests/smoke/test_affinity_groups_projects.py took 421
> seconds
>Test /marvin/tests/smoke/test_affinity_groups.py took 268 seconds
>Test /marvin/tests/smoke/test_certauthority_root.py took 44 seconds
>Test /marvin/tests/smoke/test_deploy_vgpu_enabled_vm.py took 501
> seconds
>Test /marvin/tests/smoke/test_deploy_virtio_scsi_vm.py took 6 seconds
>Test /marvin/tests/smoke/test_deploy_vm_iso.py took 244 seconds
>Test /marvin/tests/smoke/test_deploy_vm_root_resize.py took 158 seconds
>Test /marvin/tests/smoke/test_deploy_vms_with_varied_deploymentplanners.py
> took 674 seconds
>Test /marvin/tests/smoke/test_deploy_vm_with_userdata.py took 400
> seconds
>Test /marvin/tests/smoke/test_disk_offerings.py took 5 seconds
>Test /marvin/tests/smoke/test_dynamicroles.py took 115 seconds
>Test /marvin/tests/smoke/test_global_settings.py took 5 seconds
>Test /marvin/tests/smoke/test_guest_vlan_range.py took 26 seconds
>Test /marvin/tests/smoke/test_host_annotations.py took 14 seconds
>Test /marvin/tests/smoke/test_hostha_simulator.py took 6 seconds
>Test /marvin/tests/smoke/test_host_maintenance.py took 772 seconds
>Test /marvin/tests/smoke/test_internal_lb.py took 16104 seconds
>Test /marvin/tests/smoke/test_iso.py took 278 seconds
>Test /marvin/tests/smoke/test_list_ids_parameter.py took 1883 seconds
>Test /marvin/tests/smoke/test_loadbalance.py took 2814 seconds
>Test /marvin/tests/smoke/test_login.py took 25 seconds
>Test /marvin/tests/smoke/test_metrics_api.py took 367 seconds
>Test /marvin/tests/smoke/test_multipleips_per_nic.py took 268 seconds
>Test /marvin/tests/smoke/test_nested_virtualization.py took 415 seconds
>Test /marvin/tests/smoke/test_network_acl.py took 364 seconds
>Test /marvin/tests/smoke/test_network.py took 3628 seconds
>Test /marvin/tests/smoke/test_nic_adapter_type.py took 12 seconds
>Test /marvin/tests/smoke/test_nic.py took 1676 seconds
>Test /marvin/tests/smoke/test_non_contigiousvlan.py took 21 seconds
>Test /marvin/tests/smoke/test_outofbandmanagement_nestedplugin.py took
> 93 seconds
>Test /marvin/tests/smoke/test_outofbandmanagement.py took 230 seconds
>Test /marvin/tests/smoke/test_over_provisioning.py took 5 seconds
>Test /marvin/tests/smoke/test_password_server.py took 500 seconds
>Test /marvin/tests/smoke/test_portable_publicip.py took 58 seconds
>Test /marvin/tests/smoke/test_portforwardingrules.py took 355 seconds
>Test /marvin/tests/smoke/test_primary_storage.py took 1098 seconds
>Test /marvin/tests/smoke/test_privategw_acl.py took 2634 seconds
>Test /marvin/tests/smoke/test_projects.py took 865 seconds
>Test /marvin/tests/smoke/test_public_ip_range.py took 11 seconds
>Test /marvin/tests/smoke/test_pvlan.py took 10 seconds
>Test /marvin/tests/smoke/test_regions.py took 6 seconds
>Test /marvin/tests/smoke/test_reset_vm_on_reboot.py took 420 seconds
>Test /marvin/tests/smoke/test_resource_detail.py took 16 seconds
>Test /marvin/tests/smoke/test_router_dhcphosts.py took 1491 seconds
>Test /marvin/tests/smoke/test_router_dns.py took 366 seconds
>Test /marvin/tests/smoke/test_router_dnsservice.py took 395 seconds
>Test /marvin/tests/smoke/test_routers_iptables_default_policy.py took
> 1605 seconds
>Test /marvin/tests/smoke/test_routers_network_ops.py took 3760 seconds
>Test /marvin/tests/smoke/test_routers.py took 800 seconds
>Test /marvin/tests/smoke/test_scale_vm.py took 438 seconds
>Test /marvin/tests/smoke/test_secondary_storage.py took 6 seconds
>Test /marvin/tests/smoke/test_service_offerings.py took 497 seconds
>Test /marvin/tests/smoke/test_snapshots.py took 390 seconds
>Test /marvin/tests/smoke/test_ssvm.py took 1142 seconds
>Test /marvin/tests/smoke/test_staticroles.py took 5 seconds
>Test /marvin/tests/smoke/test_templates.py took 2172 seconds
>Test /marvin/tests/smoke/test_usage_events.py took 5 seconds
>Test /marvin/tests/smoke/test_usage.py took 3223 seconds
>Test /marvin/tests/smoke/test_vm_life_cycle.py took 3197 seconds
>Test /marvin/tests/smoke/test_vm_snapshots.py took 1677 seconds
>Test /marvin/tests/smoke/test_volumes.py took 707 seconds
>Test 

Re: [jira] [Closed] (CLOUDSTACK-620) Allow additional JVM opts and classpath injection

[Mohammad Aladwan]

Dear all,

I don't know if this the right place, please if my question in another
section, redirect me.

i have question, whats the way protect ISO image in cloudstack from any
attack.

thanks

On Mon, Jun 6, 2016 at 3:19 PM, Wido den Hollander (JIRA) 
wrote:

>
>  [
> https://issues.apache.org/jira/browse/CLOUDSTACK-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> Wido den Hollander closed CLOUDSTACK-620.
> -
> Resolution: Fixed
>
> With the move to systemd this is resolved there.
>
> You can change the systemd service file and/or override it.
>
> > Allow additional JVM opts and classpath injection
> > --
> >
> > Key: CLOUDSTACK-620
> > URL:
> https://issues.apache.org/jira/browse/CLOUDSTACK-620
> > Project: CloudStack
> >  Issue Type: Improvement
> >  Security Level: Public(Anyone can view this level - this is the
> default.)
> >Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0
> > Environment: ubuntu
> >Reporter: Pierre-Yves Ritschard
> >Priority: Minor
> >
> > The rationale is to allow configuration management to push
> > specific log4j configurations or JMX arguments directly through
> > `/etc/default/cloud-agent` instead of having to modify the startup
> script.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>

Re: [jira] [Created] (CLOUDSTACK-9406) Enable IPv6 Link-Local in cloud0 interface in System VMs

[Mohammad Aladwan]

Dear all,

I don't know if this the right place, please if my question in another
section, redirect me.

i have question, whats the way protect ISO image in cloudstack from any
attack.

thanks

On Mon, Jun 6, 2016 at 3:35 PM, Wido den Hollander (JIRA) 
wrote:

> Wido den Hollander created CLOUDSTACK-9406:
> --
>
>  Summary: Enable IPv6 Link-Local in cloud0 interface in System
> VMs
>  Key: CLOUDSTACK-9406
>  URL:
> https://issues.apache.org/jira/browse/CLOUDSTACK-9406
>  Project: CloudStack
>   Issue Type: Improvement
>   Security Level: Public (Anyone can view this level - this is the
> default.)
>   Components: KVM, SystemVM
> Reporter: Wido den Hollander
>
>
> Currently a 169.254.0.0/16 address is used for communication between the
> (KVM) hypervisor and a System VM.
>
> The address is provided through a socket to the SSVM on startup.
>
> This adds additional complexity since such an address needs to be recorded
> in the database.
>
> IPv6 provides the Link-Local address starting with fe80:: where it is
> calculated based on the MAC-address.
>
> This address could be used to communicate with the SSVM without any prior
> communication with it. The Hypervisor knows the MAC address of the SSVM and
> thus it knows which address the SSVM will obtain.
>
> On this address a provisioning daemon could run instead of the current
> 'patch via socket' scripts.
>
> Over this address the SSVM could even expose a complete REST-full API
> which can be used to talk to the SSVM.
>
> Using the IPv6 link-local address would be the first step to IPv6 in the
> SSVM.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>

Re: [jira] [Commented] (CLOUDSTACK-9405) listDomains API call takes an extremely long time to respond

[Mohammad Aladwan]

Dear all,

I don't know if this the right place, please if my question in another
section, redirect me.

i have question, whats the way protect ISO image in cloudstack from any
attack.

thanks