[jira] [Updated] (CLOUDSTACK-9763) vpc: can not ssh to instance after vpc restart
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Sernbrant updated CLOUDSTACK-9763: - Description: Restart with Cleanup of a VPC does not update the public-key metadata, it is explicitly set to null in https://github.com/apache/cloudstack/blob/master/server/src/com/cloud/network/router/CommandSetupHelper.java#L614 Rebooting instances relying on metadata (e.g. coreos) will no longer have the correct public key configured. Added explanation: The VPC VR maintains metadata (http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/4.8/virtual_machines/user-data.html) as static files in /var/www/html/metadata. When a VR is destroyed and recreated (by e.g. "restart with cleanup") this metadata is rebuilt by createVmDataCommandForVMs(). public-keys is missing from that function so it becomes empty after the rebuild and a request for latest/meta-data/public-keys no longer returns the correct key. was: Restart with Cleanup of a VPC does not update the public-key metadata, it is explicitly set to null in https://github.com/apache/cloudstack/blob/master/server/src/com/cloud/network/router/CommandSetupHelper.java#L614 Rebooting instances relying on metadata (e.g. coreos) will no longer have the correct public key configured. > vpc: can not ssh to instance after vpc restart > -- > > Key: CLOUDSTACK-9763 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9763 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router, VPC >Affects Versions: 4.8.0 >Reporter: Joakim Sernbrant > > Restart with Cleanup of a VPC does not update the public-key metadata, it is > explicitly set to null in > https://github.com/apache/cloudstack/blob/master/server/src/com/cloud/network/router/CommandSetupHelper.java#L614 > Rebooting instances relying on metadata (e.g. coreos) will no longer have the > correct public key configured. > Added explanation: > The VPC VR maintains metadata > (http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/4.8/virtual_machines/user-data.html) > as static files in /var/www/html/metadata. When a VR is destroyed and > recreated (by e.g. "restart with cleanup") this metadata is rebuilt by > createVmDataCommandForVMs(). public-keys is missing from that function so it > becomes empty after the rebuild and a request for > latest/meta-data/public-keys no longer returns the correct key. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] (CLOUDSTACK-9763) vpc: can not ssh to instance after vpc restart
Title: Message Title Joakim Sernbrant updated an issue CloudStack / CLOUDSTACK-9763 vpc: can not ssh to instance after vpc restart Change By: Joakim Sernbrant Restart with Cleanup of a VPC does not update the public-key metadata, it is explicitly set to null in https://github.com/apache/cloudstack/blob/master/server/src/com/cloud/network/router/CommandSetupHelper.java#L614 Rebooting instances relying on metadata (e.g. coreos) will no longer have the correct public key configured. Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d)
[jira] (CLOUDSTACK-9763) vpc: can not ssh to instance after vpc restart
Title: Message Title Joakim Sernbrant updated an issue CloudStack / CLOUDSTACK-9763 vpc: can not ssh to instance after vpc restart Change By: Joakim Sernbrant Restart with Cleanup of a VPC does not update the public-key metadata, it is explicitly set to null in https://github.com/apache/cloudstack/blob/master/server/src/com/cloud/network/router/CommandSetupHelper.java#L614 Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d)
[jira] (CLOUDSTACK-9763) vpc: can not ssh to instance after vpc restart
Title: Message Title Joakim Sernbrant created an issue CloudStack / CLOUDSTACK-9763 vpc: can not ssh to instance after vpc restart Issue Type: Bug Affects Versions: 4.8.0 Assignee: Unassigned Components: Virtual Router, VPC Created: 30/Jan/17 15:07 Priority: Major Reporter: Joakim Sernbrant Security Level: Public (Anyone can view this level - this is the default.) Restart with Cleanup of a VPC does not update the public-key metadata, it is explicitly set to null in
[jira] [Commented] (CLOUDSTACK-9746) system-vm: logrotate config causes critical failures
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15834281#comment-15834281 ] Joakim Sernbrant commented on CLOUDSTACK-9746: -- Proposed fix: Rotate both daily and by size by using maxsize in stead of size. Decrease the max size to 10M and reduce the number of kept files to a maximum of 5. > system-vm: logrotate config causes critical failures > > > Key: CLOUDSTACK-9746 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9746 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.8.0, 4.9.0 >Reporter: Joakim Sernbrant >Priority: Critical > > CLOUDSTACK-6885 changed logrotate from time based to size based. This means > that logs will grow up to its size times two (due to delaycompress). > For example: > 50M auth.log > 50M auth.log.1 > 10M cloud.log > 10M cloud.log.1 > 50M cron.log > 50M cron.log.1 > 50M messages > 50M messages.1 > ... > Some files will grow slowly but eventually they will get to their max size. > The total allowed log size with the current config is well beyond the size of > the log partition. > Having a full /dev/log puts the VR in a state where operations on it > critically fails. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9746) system-vm: logrotate config causes critical failures
Joakim Sernbrant created CLOUDSTACK-9746: Summary: system-vm: logrotate config causes critical failures Key: CLOUDSTACK-9746 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9746 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.9.0, 4.8.0 Reporter: Joakim Sernbrant Priority: Critical CLOUDSTACK-6885 changed logrotate from time based to size based. This means that logs will grow up to its size times two (due to delaycompress). For example: 50M auth.log 50M auth.log.1 10M cloud.log 10M cloud.log.1 50M cron.log 50M cron.log.1 50M messages 50M messages.1 ... Some files will grow slowly but eventually they will get to their max size. The total allowed log size with the current config is well beyond the size of the log partition. Having a full /dev/log puts the VR in a state where operations on it critically fails. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8993) DHCP fails with "no address available" when an IP is reused
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joakim Sernbrant updated CLOUDSTACK-8993:
-
Summary: DHCP fails with "no address available" when an IP is reused (was:
DHCP fails with "no address available" with an IP is reused)
> DHCP fails with "no address available" when an IP is reused
> ---
>
> Key: CLOUDSTACK-8993
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8993
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: SystemVM
>Affects Versions: 4.6.0
>Reporter: Joakim Sernbrant
>
> CsDhcp.process() appends new entries to /etc/dhcphosts.txt causing duplicates
> like:
> {code}
> 06:49:14:00:00:4d,10.7.32.107,node1,infinite
> 06:42:b0:00:00:3a,10.7.32.107,node2,infinite
> {code}
> This makes dnsmasq fail with "no address available".
> CsDhcp.process() should repopulate the file to remove old entries with the
> same IP address.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8993) DHCP fails with "no address available" with an IP is reused
Joakim Sernbrant created CLOUDSTACK-8993:
Summary: DHCP fails with "no address available" with an IP is
reused
Key: CLOUDSTACK-8993
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8993
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: SystemVM
Affects Versions: 4.6.0
Reporter: Joakim Sernbrant
CsDhcp.process() appends new entries to /etc/dhcphosts.txt causing duplicates
like:
{code}
06:49:14:00:00:4d,10.7.32.107,node1,infinite
06:42:b0:00:00:3a,10.7.32.107,node2,infinite
{code}
This makes dnsmasq fail with "no address available".
CsDhcp.process() should repopulate the file to remove old entries with the same
IP address.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
