Under Linux, the shared subtree flags control how a mountpoint is shared with parent and child mount namespaces. These flags include MS_SHARED, MS_PRIVATE, and MS_SLAVE. How can one see which of these flags are set on a particular mountpoint?
These flags don't show up in the output of mount or in /proc/mounts.
The <component> element in an unattend.xml file -- used to provide information required by fully automated Windows installs -- is generally presented with a number of attributes, for example:
<component
name="Microsoft-Windows-International-Core-WinPE"
processorArchitecture="amd64"
publicKeyToken="31bf3856ad364e35"
language="neutral"
versionScope="nonSxS">
<!-- ... -->
</component>
While name and processorArchitecture are fairly self-explanatory, and language suggests that maybe it introduces locale-specific settings, I have not been able to find any documentation on any of these attributes.
In particular, what are versionScope and publicKeyToken? At the moment they seem to be "magical constants".
I am trying to perform an unattended install of Windows Server 2012
into a KVM virtual machine, using virt-install. The installer is
complaining, "Windows cannot read the <ProductKey> setting from the
unattend answer file", and I've been unable to figure out how to
proceed past this point.
I am starting with the following autounattend.xml file:
<unattend xmlns="urn:schemas-microsoft-com:unattend"
xmlns:ms="urn:schemas-microsoft-com:asm.v3"
xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State">
<settings pass="windowsPE">
<component name="Microsoft-Windows-Setup"
publicKeyToken="31bf3856ad364e35" language="neutral"
versionScope="nonSxS" processorArchitecture="x86">
<UserData>
<AcceptEula>true</AcceptEula>
<ProductKey>
<Key>XXXXX-XXXXX-XXXXX-XXXXX-XXXXX</Key>
<WillShowUI>OnError</WillShowUI>
</ProductKey>
</UserData>
<ImageInstall>
<OSImage>
<WillShowUI>Never</WillShowUI>
<InstallTo>
<DiskID>0</DiskID>
<PartitionID>1</PartitionID>
</InstallTo>
<InstallFrom>
<MetaData>
<Key>/IMAGE/Name</Key>
<Value>Windows Longhorn SERVERSTANDARDCORE</Value>
</MetaData>
</InstallFrom>
</OSImage>
</ImageInstall>
</component>
</settings>
</unattend>
I am baking this into an ISO image using mkisofs:
$ ls config/
autounattend.xml
$ mkisofs -o config.iso -J -r config
And then I'm starting the install like this:
virt-install -n ws2012 -r 2048 -w network=default,model=virtio \
--disk path=ws2012.qcow2,device=disk,bus=virtio \
--cdrom en_windows_server_2012_r2_with_update_x64_dvd_4065220.iso \
--disk path=virtio-win-0.1-81.iso,device=cdrom \
--disk path=config.iso,device=cdrom \
--os-type windows --os-variant win2k8
Looking at x:\windows\panther\setupact.log, I can see that the
installer does find the unattend file:
2014-11-14 12:29:43, Info [0x060114] IBS
Callback_Productkey_Validate_Unattend:User specified an unattend
xml file
The specified product key is valid (I can copy and paste it from this file into the product key dialog and the installation will proceed correctly).
Do you know how to make this install work?
I am trying to implement a 9000 byte MTU for storage communication between KVM guests and the host system. The host has a bridge (br1) with a 9000 byte MTU:
host# ip link show br1
8: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP
link/ether fe:54:00:50:f3:55 brd ff:ff:ff:ff:ff:ff
inet 172.16.64.1/24 brd 172.16.64.255 scope global br1
inet6 fe80::21b:21ff:fe0e:ee39/64 scope link
valid_lft forever preferred_lft forever
The guests have an interface attached to this bridge that also has a 9000 byte MTU:
guest# ip addr show eth2
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP qlen 1000
link/ether 52:54:00:50:f3:55 brd ff:ff:ff:ff:ff:ff
inet 172.16.64.10/24 brd 172.16.64.255 scope global eth2
inet6 fe80::5054:ff:fe50:f355/64 scope link
valid_lft forever preferred_lft forever
I can ping from the host to the guest:
host# ping -c4 172.16.64.10
PING 172.16.64.10 (172.16.64.10) 56(84) bytes of data.
64 bytes from 172.16.64.10: icmp_seq=1 ttl=64 time=1.15 ms
64 bytes from 172.16.64.10: icmp_seq=2 ttl=64 time=0.558 ms
64 bytes from 172.16.64.10: icmp_seq=3 ttl=64 time=0.566 ms
64 bytes from 172.16.64.10: icmp_seq=4 ttl=64 time=0.631 ms
--- 172.16.64.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.558/0.727/1.153/0.247 ms
But if I increase the ping packet size beyond 1490 bytes, I no longer have connectivity:
host# ping -c4 -s 1491 172.16.64.10
PING 172.16.64.10 (172.16.64.10) 1491(1519) bytes of data.
--- 172.16.64.10 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3000ms
A packet trace shows that these packets never reach the guest. Everything I've read indicates that both the Linux bridge interface and the virtio network drives all support jumbo frames, but this sure looks like an MTU problem to me.
Am I missing something really obvious?
Update
Showing the host-side of the guest interface:
host# brctl show
bridge name bridge id STP enabled interfaces
br1 8000.fe540050f355 no vnet2
host# ip addr show vnet2
11: vnet2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast master br1 state UNKNOWN qlen 500
link/ether fe:54:00:50:f3:55 brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc54:ff:fe50:f355/64 scope link
valid_lft forever preferred_lft forever
I need to automate the provisioning of a cloud instance (running Fedora 17) for which the following initial facts are true:
cloud)sudo.Manual configuration is as simple as logging in and running sudo su - and having at it, but I would like to fully automate this process. The trick is that the system defaults to having the requiretty option enabled for sudo, which means that an attempt to do something like this:
ssh remotehost sudo yum -y install puppet
Will fail:
sudo: sorry, you must have a tty to run sudo
I am working around this right now by first pushing over a small Python script that will run a command on a pseudoterminal:
import os
import sys
import errno
import subprocess
pid, master_fd = os.forkpty()
if pid == 0:
# child process: now that we're attached to a
# pty, run the given command.
os.execvp(sys.argv[1], sys.argv[1:])
else:
while True:
try:
data = os.read(master_fd, 1024)
except OSError, detail:
if detail.errno == errno.EIO:
break
if not data:
break
sys.stdout.write(data)
os.wait()
Assuming that this is named pty, I can then run:
ssh remotehost ./pty sudo yum -y install puppet
This works fine, but I'm wondering if there are solutions already available that I haven't considered.
expect, but it's not installed by default on this system.screen can do this in a pinch, but the best I came up with was:
screen -dmS sudo somecommand
...which does work but eats the output.
Are there any other tools available that will allocate a pseudoterminal for me that are going to be generally available?
I am trying to figure out the path of least resistance in OpenStack to get from a live CD to a disk image that can be used for deploying new guest instances.
If you boot an OpenStack instance from a live CD, you can install an OS onto the "ephemeral" disk (which will, in this case, be /dev/vda)...
...that's great, but there's no way to create an image from that disk; the image-create command will attempt (and fail) to snapshot the live CD itself (because this is the boot volume).
You can create and attach a new volume (using volume-create and volume-attach) and then install the OS on that, but there's doesn't appear to be any way to convert this volume into a Glance-hosted image for use by other instances.
As an administrator I can obviously log in to the storage host and create a new glance image directly from the volume block device, but this isn't an avenue available to anyone interacting via the API or web GUI.
Are there any other options available?
In setting up our OpenStack environment, I ran into a problem that was preventing instances from contacting a server running on the host. The metadata service (which exposes an HTTP API) runs on port 8775 on the host, and the OpenStack networking code adds the following DNAT rule to grant access via a special address on port 80:
-A PREROUTING -d 169.254.169.254/32
-p tcp -m tcp --dport 80 -j DNAT --to-destination 127.0.0.1:8775
Instances are connected to the host via a local bridge device, and 169.254.169.254 is assigned to lo.
While this rule successfully matches packets originating from a guest instance trying to access http://169.254.168.254/, they never reach the listening service.
Replacing this DNAT rule with a largely equivalent REDIRECT makes everything work correctly:
-A PREROUTING -d 169.254.169.254/32
-p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8775
I'm trying to understand why the REDIRECT works and the DNAT fails. It's not clear from the iptables documentation whether or not the DNAT rule is expected to work for locally destined traffic. I'm hoping someone here can provide an authoritative answer, ideally backed up by documentation, or can suggest what might be amiss in my configuration that is preventing the DNAT rule from working as expected.
I have a Puppet class that sets up a number of services and configuration files. In most cases, there is a default server that can be used, but it is also possible to configure explicit per-service servers. I find myself doing this all the time:
class myclass (
$default_server = 'server.example.com',
$server_for_thing1 = undef,
$server_for_thing2 = undef,
$server_for_thing3 = undef
) {
if $server_for_thing1 {
$real_server_for_thing1 = $server_for_thing1
} else {
$real_server_for_thing1 = $default_server
}
# ...and so forth...
}
As the number of possible services grows large, this syntax becomes unwieldy. Is there a better way of doing this? I really want something along the lines of:
$server_for_thing1 = $server_for_thing1 || $default_server
...but variables cannot be re-assigned in Puppet. Are there better ways of doing this?
I work in an academic environment where we are providing a variety of ssh-accessible compute resources. We also provide git repository hosting, and we require ssh for read/write access to the repositories.
Our instructions for OS X and Linux users are relatively simple and, most importantly, consistent -- both with OS X and most modern Linux distributions, OpenSSH is included out-of-the-box and, more importantly, ssh-agent is preconfigured to run whenever a desktop session is active. We generally encourage people to assign passphrases to their keys, so life without an authentication agent can rapidly become annoying.
Our solutions for Windows users are at the moment both more fragmented and more complicated in general. Historically people have been using PuTTY, but this requires extra steps to produce OpenSSH-compatible keys. It also makes it more difficult -- though not, I realize, impossible -- to use the git command line tools, which works best with OpenSSH when interacting with ssh-accessible repositories.
We would like to simply have folks install msysgit, but we're looking at a good way to integrate ssh-agent into the Windows desktop environment. The most common solution out there is to start the agent via entries in .bashrc, but that seems hacky at best and it means we have to guide largely non-technical users through the process of editing their .bashrc under Windows.
An additional complication is that WinSCP is often used as a file transfer tool -- and of course this won't talk to ssh-agent. It will talk to pagent, from the PuTTY folks, but pagent doesn't speak ssh-agent so it won't work from the command line.
What have other folks done to provide a consistent environment for users on different platforms? Have you just thrown up your hands and decided to maintain a separate set of documents for Windows users?
UPDATE
I've found two programs that act as a shim between OpenSSH and pagent. Do you have any experience with either charade or ssh-pagent?
I work in an environment where some people are using Microsoft Exchange and some people are not. The meeting invitations sent out by Exchange include a text/calendar attachment with the meeting information in iCal format. They also include an empty text/plain and an empty text/html part.
Is there any way to configure Exchange such that it will populate either (or both!) the text/plain or the text/html part with a human-readable version of the meeting summary? This would help out people using mail clients that do not have native support for text/calendar attachments.
We have a local LDAP directory that provides basic contact information about our user community. We would like to integrate this into some third-party hosted services that allow us to implement widgets that run arbitrary Javascript.
In order to connect Javascript to our LDAP directory, I would like to set up a simple LDAP-to-HTTP proxy that would accept HTTP GET requests, translate them into an appropriate LDAP query, and respond with directory information as JSON-encoded data.
In an ideal world, something like this:
GET /[email protected]
Would get me something like this:
{
"cn": "Bob Person",
"title": "System Administrator",
"sn": "Person",
"mail": "[email protected]",
"telepehoneNumber": "617-555-1212",
"givenName": "Bob"
}
(And this obviously assumes that the web application has locally configured information about what base DN to use, how to authenticate, etc).
I guess I could write one...but surely something like this already exists?
We've recently started experimenting with IPv6, and one of the first issues we're having to contend with is dealing with a completely separate set of firewall (Linux iptables/ip6ables) rules for the two protocol stacks. Our firewall logic is based largely around a number of purpose-specific networks (e.g., 10.0.0.0/24 is the staff workstation network, 10.1.0.0/24 is the database network, 10.2.0.0/24 is the web server network, etc), and the logic for both IPv6 and IPv4 will be largely the same, modulo different network prefixes.
What are people doing do manage this sort of situation? Ideally I would like to be able to generate both iptables and ip6table rulesets from the same source file(s). I have already thrown together something using bash, but it's not necessarily pretty and I suspect that a better solution must exist somewhere out there.
I would be particularly interested in a Puppet-based solution that makes good use of Puppet's own dependency mechanisms to implement relative ordering of rules (or groups of rules).
I have recently started experimenting with the support for passthrough filesystems in recent versions of KVM/QEMU/libvirt. Making the filesystems available for read access has "just worked", but I'm a little puzzled about how write access is supposed to work. After mounting the filesystem in the guest:
# mount -t 9p -o trans=virtio /fs/data /mnt
I can modify an existing file if it has mode o+w:
# cd /mnt/work
# ls -l foo
-rw-rw-rw-. 1 root root 17 Dec 20 11:16 foo
# cat foo
this is line one
# echo this is line two >> foo
# cat foo
this is line one
this is line two
But regardless of the directory permissions, I cannot create a new file or directory:
# ls -ld /mnt/work
drwxrwxrwx. 2 root root 4096 Dec 20 11:16 /mnt/work
# cd /mnt/work
# touch bar
touch: setting times of `bar': No such file or directory
# mkdir bar
# mkdir: cannot create directory `bar': Operation not permitted
The documentation I've been able to find (e.g., this) does not explicitly address this issue. I'm hoping someone here at Serverfault can help me set up a passthrough filesystem that will let me grant write access to a user in the guest to a host filesystem.
I am looking at network-attached USB hubs in order to run licensed software in a virtualized environment when hardware dongles are required.
Are there any solutions that will work with both Linux and Windows? Most of the dedicated devices -- such as the Zonet ZUH2214 or the (oddly expensive) Digi AnywherUSB/2 -- appear to be Windows-only. Linux has the the USB/IP project, for which there appear to be Windows drivers, but the last "News" post on the site was in 2007, so I'm not entirely confident about the viability of the project.
Has anyone out there found a solution that will work well in both environments?
We would like to use gpg signatures to verify some aspects of our system configuration management tools. Additionally, we would like to use a "trust" model where individual sysadmin keys are signed with a master signing key, and then our systems trust that master key (and use the "web of trust" to validate signatures by our sysadmins).
This gives us a lot of flexibility, such as the ability to easily
revoke the trust on a key when someone leaves, but we've run into a
problem. While the gpg command will tell you if a key is
untrusted, it doesn't appear to return an exit code indicating this
fact. For example:
# gpg -v < foo.asc
Version: GnuPG v1.4.11 (GNU/Linux)
gpg: armor header:
gpg: original file name=''
this is a test
gpg: Signature made Fri 22 Jul 2011 11:34:02 AM EDT using RSA key ID ABCD00B0
gpg: using PGP trust model
gpg: Good signature from "Testing Key <[email protected]>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: ABCD 1234 0527 9D0C 3C4A CAFE BABE DEAD BEEF 00B0
gpg: binary signature, digest algorithm SHA1
The part we care about is this:
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
The exit code returned by gpg in this case is 0, despite the trust failure:
# echo $?
0
How do we get gpg to fail in the event that something is signed with an untrusted signature?
I've seen some suggestions that the gpgv command will return a proper exit code, but unfortunately gpgv doesn't know how to fetch keys from keyservers. I guess we can parse the status output (using --status-fd) from gpg, but is there a better way?
I'm having a problem with the following Puppet manifest, which is meant
to enable the passwdqc pam module on a RHEL-6 system (this is using
Puppet 0.25.5 and augeas 0.7.2):
augeas { 'authconfig':
context => '/files/etc/sysconfig/authconfig',
changes => [
'set USEPASSWDQC yes',
'set USECRACKLIB no',
],
notify => Exec['authconfig-all'],
}
exec { 'authconfig-all':
command => '/usr/sbin/authconfig --updateall',
refreshonly => true,
}
If I run this manifest, it appears to complete successfully:
info: Applying configuration version '1311189237'
notice: //Augeas[authconfig]/returns: executed successfully
info: //Augeas[authconfig]: Scheduling refresh of Exec[authconfig-all]
notice: //Exec[authconfig-all]: Triggering 'refresh' from 1 dependencies
But if I examine the target file, the changes have not been applied:
# egrep 'PASSWDQC|CRACKLIB' /etc/sysconfig/authconfig
USECRACKLIB=yes
USEPASSWDQC=no
If I remove the notify => ... line from the manifest, it works
exactly as intended. That is, given this:
augeas { 'authconfig':
context => '/files/etc/sysconfig/authconfig',
changes => [
'set USEPASSWDQC yes',
'set USECRACKLIB no',
],
}
The changes are successfully saved:
# puppet /path/to/manifest.pp
info: Applying configuration version '1311189502'
notice: //Augeas[authconfig]/returns: executed successfully
# egrep 'PASSWDQC|CRACKLIB' /etc/sysconfig/authconfig
USECRACKLIB=no
USEPASSWDQC=yes
Any idea what's going on here? Obviously puppet believes that the
change is being made the first time around, but it's not actually
getting saved to disk. We have other configurations using augeas and
notify operations that work just fine; we haven't been able to figure
out why this is failing. Note that the same problem exists if I replace notify on the augeas operation with subscribe on the corresponding exec definition.
My current plan is to build packages out of more recent versions of puppet and augeas and see if the problem will Magically Go Away.
UPDATE: freiheit points out that authconfig appears to be overwriting this file. Oddly enough, under CentOS 5, modifying /etc/sysconfig/authconfig and then running authconfig --updateall was exactly the correct procedure. This is what we're actually using in our legacy Kickstart.
So apparently the RHEL6 upgrade has made authconfig behave in strange and unhelpful ways.
I am trying to expose a hierarchy of home directories to a number of FreeBSD jails. The home directories are configured such that each is a unique ZFS dataset. The jails are used for development work and hence are created and destroyed on a regular basis.
My first thought was simply to use nullfs to mount /home inside the jail, but nullfs doesn't provide any way to access subordinate filesystems.
My second thought was to export the directories via NFS and then run the automounter daemon (amd) inside each jail. This would have Just Worked...if it were possible to perform NFS mounts inside a jail. But it's not.
My third thought was to run amd on the host and provision nullfs mounts into the jails...but amd support for nullfs doesn't exist.
My fourth thought was to go back to exporting the directories using NFS, because of course amd works with NFS, right? Unfortunately, rather than mounting a directory on the target mountpoint, amd likes to mount things in a temporary location (/.amd_mnt/...) and then create a symlink...which, of course, is useless inside the jail environment.
So maybe you could use nullfs to expose a subdirectory of /.amd_mnt to the jail? No! This brings us back to my first attempt, in which we find that there is no way to access subordinate filesystems using nullfs.
And then my head exploded.
Is there a good solution for what I'm trying to do? A bad solution would be to run a script after booting the jail that would create multiple nullfs mountpoints for each home directory, but this is pretty clunky -- it would need to be run periodically to take into account new directories or removed directories. So basically I would have to write a bad automounter.
There must be a better way. Help me, Serverfault, you're my only hope!
UPDATE 1: It occurred to me that I might be able to solve part of the problem with pam_mount, although this would at best be incomplete. Also, it's not clear from the documentation whether or not pam_mount can automatically create the target mountpoint. If it requires the mountpoint to exist a priori, this solution wouldn't be any better than the bad automounter I've already proposed.
UPDATE 2: As discussed in the answers below, setting VFCF_JAIL on the NFS filesystem does allow jails to perform NFS mounts. Unfortunately, the automounter continues to behave that are unhelpful, and when run in a jail appears to be very good at getting wedged in such a way that a system reboot is necessary to remove the process entry.
ZFS under FreeBSD lets one assign filesystems to a jail, such that an account in the jail with the appropriate privileges can access the filesystem, create new subordinate filesystems, and so forth. At least with 8-STABLE, these features are not integrated into the existing /etc/rc.d/jail script. The basic process looks something like:
sysctl -w security.jail.enforce_statfs=0
sysctl -w security.jail.mount_allowed=1
zfs set jailed=on <filesystem>
zfs jail <jid> <filesystem>
And also requires exposing the zfs device node inside the jail.
At the same time, there appear to be a profusion of tools out there (ezjail, jailer, warden, and generally /usr/ports/sysutils/*jail*) that claim to be easier/better/more powerful/etc, but most of which appear to only be lightly maintained and not really much of a win vs. the standard jail script.
I would like to avoid reinventing the wheel. Is there a jail management tool out there that is well integrated with ZFS? I'm looking for something that would take care of setting up the necessary devfs rules, sysctl settings, and zfs attributes when booting a jail...and ideally permit name-based references to jails, which while supported by many of the third-party tools is tragically missing from the stock jail script.
I would like to provide access to some mailing lists via a set of public, read-only mailboxes in Dovecot. I have a public namespace define in my dovecot (dovecot-2.0.9) configuration that looks like this:
namespace {
type = public
separator = .
prefix = news.
location = maildir:/var/spool/news
subscriptions = no
}
I would like to make all the mailboxes in this namespace read-only. I've got the following configuration for the ACL plugin:
plugin {
acl = vfile:/etc/dovecot/acls:cache_secs=300
}
After perusing the documentation, it seemed as if I had a mailfolder
/var/spool/news/.foo.bar that I could place the following into
/var/spool/news/.foo.bar/dovecot-acl:
anyone rl
But that doesn't have any affect. I also tried creating a file
/usr/local/etc/dovecot/acls/news.foo.bar with the same contents, but
that didn't do anything, either. I've turned on mail debugging:
mail_debug = yes
But the log doesn't produce anything that appears to be relevant to ACL processing. I'm curious to know if anyone has gotten this to work correctly and if so if you could provide some configuration examples.
Also, if there's any way to do this that doesn't involve per-mailbox
configuration (.e.g, the ability to apply an ACL to news.* or
something), that would be awesome. Getting the documented behavior for
default ACLs working would be a step in the right direction.
Given a typical Subversion/Apache configuration using SVNParentPath, with repositories hosted
under /svn/ like this:
<Location /svn>
DAV svn
SVNParentPath /srv/source/svn/repos
SVNReposName "Subversion Repository"
AuthzSVNAccessFile /srv/source/svn/authz
Satisfy Any
AuthType Basic
AuthBasicProvider file
AuthName "Subversion Repository"
AuthUserFile /srv/source/svn/htpasswd
Require valid-user
</Location>
Is there a way to override this configuration for specific
repositories without having to host them at a different path? That
is, is there any way I can add a Location block like this...
<Location /svn/my_special_repo>
SVNPath /srv/source/svn/repos/my_special_repo
AuthzSVNAccessFile /srv/source/svn/repos/my_special_repo/conf/authz
</Location>
...and have it override the configuration provided in the
Location block for /svn? My attempts at doing this with the above
configuration have been met with weird and unhelpful errors in the
Apache error log, such as:
[Wed Feb 02 11:28:35 2011] [error] [client 10.10.209.120]
(20014)Internal error: Can't open file '/srv/source/svn/repos/svn/format':
No such file or directory
All this seems to be mod_dav_svn's way of telling me that I can't do what I'm trying to do. I'm open to solutions or alternatives!
EDIT: Well, I can see that this question has generated a lot of excitement among the readership. For the record, what I may end up doing is generating per-repository configurations for all of our existing repositories, and then abandoning the SVNParentPath based configuration. The per-repo Apache configuration is minimal, especially using something like mod_macro; the hard part will be splitting apart the global authz file. If you've done this before, tips are appreciated.