Re: [CentOS-es] Bonding
On 01/11/2013 05:45 PM, William Insuasty wrote: Buenas tardes, saludos. Necesito saber si alguien me puede ayudar con el siguiente inconveniente. Tengo un enlace de acceso a internet de 5 Mg con ISP que me da una dirección ip fija y unos dns y otro Enlace de 1 Mg con ISP que me asigna la dirección por dhcp.Tengo un computador con centos 5.4 con 3 tarjetas de red.2 para conexiones de internet y otra para la red LAN. Mi pregunta es la siguiente: Como puedo hacer para sumar esos anchos de banda y salir por un sola IP y seguir utilizando mi proxy transparente que lo tenía configurado con un solo proveedor. Había escuchado que hay que hacer Bonding pero en no es bonding, bonding es por ejemplo cuando conectas dos tarjetas de red a un mismo switch.. y a este switch le configuras algo llamado trunking (podrían ser dos switches que pertenezcan a una misma red) el trunking (bonding) sirve para mantener redundancia en una red lan, si una tarjeta se daña, el server seguirá accediendo a la misma red, pero con la mitad del desempeño. Sirve lógicamente para multiplicar la velocidad de acceso a la red lan. Ahora, lo que quieres es navegar a través de 2 (o más) redes wan, de diferentes proveedores, la idea es muy similar y usas algo que llaman coloquialmente multi-wan, o alta disponibilidad o balanceo de carga en redes wan. no es perfecto pero funciona, mira el manual en www.lartc.org para que lo implementes en centos. Tiene temillas medio manuales, etc. El otro día me topé con un linux www.zeroshell.org que te permite hacer multi-wan via una simple interfaz web.. te sugeriría que le pongas delante de tu centos para que el centos te maneje toda la transparencia que tienes, y el ZS delante te haga el balanceo de carga entre las dos wan... repito, no dudo lo puedas hacer en centos, sólo que si fuera trivial ya existiría algo así simple para ellos y al menos yo no le he encontrado... pero por favor no pensemos que el bonding en la lan entre un switch y el server es lo mismo que multi-wan... eso simplemente nos puede despistar saludos! epe realidad no se como hacerlo, si alguien me puede explicarpaso a paso como hacer dicha configuración se lo agradecería. WILLIAM INSUASTY ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Re: [CentOS] Building Dovecot CentOS 5 RPMs with custom LDAP packages
On 11/1/2013 1:44 μμ, fakessh @ wrote:
I do not know the only thing I can tell you that laziness is a value in
the computer
You are partly right.
However, IMHO building dovecot using standard openldap-devel on CentOS 5
means that, even though the final RPM works, it will use *ancient*
openldap v2.3 libraries.
If we manage to use custom openldap libaries (like those from LTB
Openldap builds) then Dovecot can be built against modern/current
Openldap v2.4 libraries. That may provide significant improvements to
the final RPM, in terms of LDAP usage.
In any case, I found the solution (based on the documentation:
http://wiki2.dovecot.org/CompilingSource); I added the following lines
(marked below with ++) in your spec file:
%build
export PATH=/usr/kerberos/bin:$PATH
#required for fdpass.c line 125,190: dereferencing type-punned
pointer will break strict-aliasing rules
++ export CPPFLAGS=${CPPFLAGS} -I/usr/local/openldap/include
++ export LDFLAGS=${LDFLAGS} -L/usr/local/openldap/lib64
export CFLAGS=$RPM_OPT_FLAGS -fno-strict-aliasing
%configure
INSTALL_DATA=install -c -p -m644 \
--docdir=%{_docdir}/%{name}-%{version} \
--disable-static \
--disable-rpath \
--with-nss \
--with-shadow\
--with-pam \
--with-gssapi=plugin \
--with-ldap=plugin \
...
So, this produces a dovecot package based on Openldap 2.4
libraries(follows excerpt from the rpmbuild output):
...
Requires(interp): /bin/sh /bin/sh /bin/sh /bin/sh
Requires(rpmlib): rpmlib(CompressedFileNames) = 3.0.4-1
rpmlib(PayloadFilesHavePrefix) = 4.0-1
Requires(pre): /bin/sh shadow-utils
Requires(post): /bin/sh chkconfig shadow-utils
Requires(preun): /bin/sh chkconfig initscripts shadow-utils
Requires(postun): /bin/sh initscripts
Requires: /bin/bash /bin/sh config(dovecot) = 1:2.1.13-3.centme
initscripts ... libldap-2.4.so.2()(64bit) ...
...
It was initially using: libldap-2.3.so.0()(64bit)
Regards,
Nick
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
[CentOS] use of hard links and diff in rsync
On 01/11/2013 07:08 PM Reindl Harald wrote: different versions of the backup daily, weekly, monthly Ah, yes, in that kind of scenario hard links would be useful. unchanged files are replaced with hard-links the destination files are virtually on the same place And so then could changes to a file be recorded in the daily version as a diff against the weekly? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Building Dovecot CentOS 5 RPMs with custom LDAP packages
On 12/1/2013 11:09 πμ, Nikolaos Milas wrote:
++ export LDFLAGS=${LDFLAGS} -L/usr/local/openldap/lib64
Or, more correctly:
export LDFLAGS=${LDFLAGS} -L/usr/local/openldap/lib64 -lldap
Nick
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
[CentOS] CentOS-announce Digest, Vol 95, Issue 4
Send CentOS-announce mailing list submissions to centos-annou...@centos.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-requ...@centos.org You can reach the person managing the list at centos-announce-ow...@centos.org When replying, please edit your Subject line so it is more specific than Re: Contents of CentOS-announce digest... Today's Topics: 1. CentOS 5.9 i386 and x86_64 Packages Available in the Continuous Release (CR) Repository (Johnny Hughes) -- Message: 1 Date: Fri, 11 Jan 2013 07:46:19 -0600 From: Johnny Hughes joh...@centos.org Subject: [CentOS-announce] CentOS 5.9 i386 and x86_64 Packages Available in the Continuous Release (CR) Repository To: CentOS-Announce centos-annou...@centos.org Message-ID: 50f017ab.10...@centos.org Content-Type: text/plain; charset=iso-8859-1 The CentOS-5.9 Packages for the i386 and x86_64 Architectures are now available via the Continuous Release (CR) Repository. The CR Announcements for CentOS-5.9 can be viewed here: http://lists.centos.org/pipermail/centos-cr-announce/2013-January/thread.html More information about the CR Repository and how to install it is available here: http://wiki.centos.org/AdditionalResources/Repositories/CR As explained in the above link, we are still doing advanced QA testing on CentOS-5.9 and there may be some minor changes before the final release. This opt-in CR Repo process allows earlier access to our best effort packages now while we complete the final CentOS-5.9 QA processes, spin the ISOs and create an installable tree. Thanks, Johnny Hughes -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature Url : http://lists.centos.org/pipermail/centos-announce/attachments/20130111/cc9e5c54/attachment-0001.bin -- ___ CentOS-announce mailing list centos-annou...@centos.org http://lists.centos.org/mailman/listinfo/centos-announce End of CentOS-announce Digest, Vol 95, Issue 4 ** ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] selinux + kvm virtualization + smartd problem
Hello,
I'm using HP homeserver where host system run CentOS 6.3 with KVM
virtualization with SELinux enabled, guests too run the same OS (but
without SELinux, but this does not matter).
Host system installed on mirrors based on sda and sdb physical disks.
sd{c..f} disks attached to KVM guest (whole disks, not partitions;
needed to use zfs (zfsonlinux) benefit features). Problem is that
disks (files in /dev) which attached to KVM guest has SELinux context
which inaccessible from context of smartd process.
[r...@srv-1.home ~]# ls -laZ /dev/sd{a..f}
brw-rw. root disk system_u:object_r:fixed_disk_device_t:s0 /dev/sda
brw-rw. root disk system_u:object_r:fixed_disk_device_t:s0 /dev/sdb
brw-rw. qemu qemu system_u:object_r:svirt_image_t:s0:c281,c675 /dev/sdc
brw-rw. qemu qemu system_u:object_r:svirt_image_t:s0:c281,c675 /dev/sdd
brw-rw. qemu qemu system_u:object_r:svirt_image_t:s0:c281,c675 /dev/sde
brw-rw. qemu qemu system_u:object_r:svirt_image_t:s0:c281,c675 /dev/sdf
[r...@srv-1.home ~]# ps axwZ | grep smart[d]
system_u:system_r:fsdaemon_t:s0 1762 ?S 0:00
/usr/sbin/smartd -q never
When I restarts smartd next messages appears in audit.log:
[r...@srv-1.home ~]# tail -F /var/log/audit/audit.log | grep type=AVC
type=AVC msg=audit(1357993548.964:8529): avc: denied { getattr } for
pid=21321 comm=smartd path=/dev/sdc dev=devtmpfs ino=6327
scontext=unconfined_u:system_r:fsdaemon_t:s0
tcontext=system_u:object_r:svirt_image_t:s0:c281,c675 tclass=blk_file
type=AVC msg=audit(1357993548.965:8530): avc: denied { getattr } for
pid=21321 comm=smartd path=/dev/sdd dev=devtmpfs ino=6321
scontext=unconfined_u:system_r:fsdaemon_t:s0
tcontext=system_u:object_r:svirt_image_t:s0:c281,c675 tclass=blk_file
type=AVC msg=audit(1357993548.966:8531): avc: denied { getattr } for
pid=21321 comm=smartd path=/dev/sde dev=devtmpfs ino=6324
scontext=unconfined_u:system_r:fsdaemon_t:s0
tcontext=system_u:object_r:svirt_image_t:s0:c281,c675 tclass=blk_file
type=AVC msg=audit(1357993548.966:8532): avc: denied { getattr } for
pid=21321 comm=smartd path=/dev/sdf dev=devtmpfs ino=6330
scontext=unconfined_u:system_r:fsdaemon_t:s0
tcontext=system_u:object_r:svirt_image_t:s0:c281,c675 tclass=blk_file
type=AVC msg=audit(1357993549.198:8533): avc: denied { read } for
pid=21321 comm=smartd name=sdc dev=devtmpfs ino=6327
scontext=unconfined_u:system_r:fsdaemon_t:s0
tcontext=system_u:object_r:svirt_image_t:s0:c281,c675 tclass=blk_file
type=AVC msg=audit(1357993549.198:8534): avc: denied { read } for
pid=21321 comm=smartd name=sdd dev=devtmpfs ino=6321
scontext=unconfined_u:system_r:fsdaemon_t:s0
tcontext=system_u:object_r:svirt_image_t:s0:c281,c675 tclass=blk_file
type=AVC msg=audit(1357993549.198:8535): avc: denied { read } for
pid=21321 comm=smartd name=sde dev=devtmpfs ino=6324
scontext=unconfined_u:system_r:fsdaemon_t:s0
tcontext=system_u:object_r:svirt_image_t:s0:c281,c675 tclass=blk_file
type=AVC msg=audit(1357993549.198:8536): avc: denied { read } for
pid=21321 comm=smartd name=sdf dev=devtmpfs ino=6330
scontext=unconfined_u:system_r:fsdaemon_t:s0
tcontext=system_u:object_r:svirt_image_t:s0:c281,c675 tclass=blk_file
I tried to create SELinux policy using audit2allow:
[r...@srv-1.home ~]# cat /var/log/audit/audit.log | grep smartd |
audit2allow -M smartd_svirt_image
[r...@srv-1.home ~]# semodule -i smartd_svirt_image.pp
but it not helped to solve problem.
How I can create permissive rule for selinux in my case?
Thank you.
--
GPG Key ID: 6EC5EB27
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] use of hard links and diff in rsync
On Sat, Jan 12, 2013 at 3:46 AM, ken geb...@mousecar.com wrote: On 01/11/2013 07:08 PM Reindl Harald wrote: different versions of the backup daily, weekly, monthly Ah, yes, in that kind of scenario hard links would be useful. Backuppc does it by matching the content, so it can pool the duplicate data even if the copies are found in different places or on different backup targets. unchanged files are replaced with hard-links the destination files are virtually on the same place And so then could changes to a file be recorded in the daily version as a diff against the weekly? I think rdiff-backup can save deltas. Rsync itself and backuppc will send deltas over the network but end up reconstructing a complete copy of the target file even for small differences. At least backuppc can compress the resulting file for storage. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] use of hard links and diff in rsync
On 2013-01-12, ken geb...@mousecar.com wrote: On 01/11/2013 07:08 PM Reindl Harald wrote: different versions of the backup daily, weekly, monthly Ah, yes, in that kind of scenario hard links would be useful. unchanged files are replaced with hard-links the destination files are virtually on the same place And so then could changes to a file be recorded in the daily version as a diff against the weekly? Not with rsync or rsnapshot. If you make a change in one line to a 48GB file, rsnapshot will remove the appropriate hard link (leaving the others alone) and create a new 48GB file at a new inode. (Because rsnapshot uses rsync, the data transfer for this change is still fast, but it's still 2x storage.) --keith -- kkel...@wombat.san-francisco.ca.us ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] selinux + kvm virtualization + smartd problem
On 01/12/2013 04:35 AM, Ilyas -- wrote: [r...@srv-1.home ~]# cat /var/log/audit/audit.log | grep smartd | audit2allow -M smartd_svirt_image [r...@srv-1.home ~]# semodule -i smartd_svirt_image.pp but it not helped to solve problem. How I can create permissive rule for selinux in my case? If you need to create your own rules, the first thing you need to do is capture the audit log, and set the system into permissive mode: tail -f /var/log/audit/audit.log In a new terminal: setenforce permissive Now, run the process that's generating AVCs. Run through its standard operations. When that's done, use all of the relevant AVCs that you captured through audit2why to make sure that there's not an existing boolean that can be flipped. Assuming there isn't, run them through audit2allow -M. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] wiping out data on a disk (no physical acess to the machine)
On 01/08/2013 02:36 PM, Carl T. Miller wrote: 1) connect using ssh and stop all services 2) swapoff /dev/sdXX 3) shred -n5 -z -v /dev/sdX I assume that all of the disks are to be shredded. Shredding non-system disks wouldn't be difficult enough to ask about. If you shred a mounted filesystem, the kernel will probably panic if it tries to read from the filesystem after shred starts overwriting data. 4) echo 1 /proc/sys/kernel/sysrq 6) echo o /proc/sysrq-trigger You wouldn't be able to do that once shred had run. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] wiping out data on a disk (no physical acess to the machine)
On 01/08/2013 02:06 PM, Yungwei Chen wrote: I need to securely wipe out a disk on a remote machine, but I don't have access to that machine. Therefore I cannot use the LiveCD+shred (or dd) combination. If you have enough RAM to hold the live disk, you can boot the whole thing from grub, probably using memdisk. If you boot a live image with memdisk, you can safely wipe the hard disks without the running kernel crashing. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] gigantic memory leak in Clock Applet...
On 01/08/2013 05:25 AM, Paul Bijnens wrote: Then I fell over: https://blogs.oracle.com/bnitz/entry/thanks_for_the_memories https://live.gnome.org/MemoryReduction which seems to imply that the shared libraries of all stuff used by Gnome gets measured in one of the gnome programs, frequently the clock-applet apparently. That implies that this problem is a red herring. I just means that during the lifetime of Gnome, there were lots of shared libraries loaded, and that memory shows up for 1 applet only. It doesn't imply that at all. Shared memory use is reported as RES for all of the applications that load the shared libraries. It's not just for one of them. Since shared libraries are also loaded when the application starts, RES will normally start out large for applications so affected. When RES grows over time, without bound, it's probably an actual memory leak. To debug the clock applet, first you'd have to kill it, and then start it under valgrind: valgrind -v --log-file=/var/tmp/clock-applet.log clock-applet Let it run until you believe it has leaked memory, then kill it again. The log file should have details about any detected memory leaks. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] wiping out data on a disk (no physical acess to the machine)
On Sat, Jan 12, 2013 at 7:05 PM, Gordon Messmer yiny...@eburg.com wrote: On 01/08/2013 02:06 PM, Yungwei Chen wrote: I need to securely wipe out a disk on a remote machine, but I don't have access to that machine. Therefore I cannot use the LiveCD+shred (or dd) combination. If you have enough RAM to hold the live disk, you can boot the whole thing from grub, probably using memdisk. If you boot a live image with memdisk, you can safely wipe the hard disks without the running kernel crashing. at $long_ago_job we'd use a pxe-netboot image; effectively DBAN (http://www.dban.org/). which only really works if you have another server in the remote location to act as the pxe server.maybe if you were really playful (and had throw away hardware to try it on) you could figure a way to extract the dban iso into the boot partition of the remote machine, do a reboot and let it go? about all I can think of. -- Even the Magic 8 ball has an opinion on email clients: Outlook not so good. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Why is localhost self-signed cert a CA cert?
On 01/08/2013 05:30 PM, Robert Moskowitz wrote: I know that I would have to take this to bugzilla if my reading was correct. And on further review, I am holding more that way. So I will put in the bug report even without being a paying customer. Just my cred on working on PKIX back a decade ago and being the architect of the Bridge CA model for the US Federal and BioPharma PKIs... cred is frequently unrecognized by developers, so my advice would be to skip that part. Stick to a description of the problem as you see it, and what solutions are available. For example: --- When mod_ssl is installed (and possibly other openssl packages) it creates a new certificate for localhost using the following command: /usr/bin/openssl req -new -key /etc/pki/tls/private/localhost.key \ -x509 -days 365 -set_serial $RANDOM \ -out /etc/pki/tls/certs/localhost.crt In the distributed openssl configuration, this will create an x509 cert which uses the extensions included in the v3_ca section of the openssl.cfg file. If any user connects to a service using such an automatically generated certificate, and accepts installation of the self-signed certificate (the default acceptance option in Firefox), it will be stored in their trusted CA list, as its constraints specify CA:True. This creates unnecessary risk. Anyone with access to such a certificate can later sign a certificate for any hostname, and users who have accepted the self-signed cert will see no warnings. If the command is modified to specify the v3_req extensions rather than the default, the resulting certificate will be equally usable, without creating undue risk for users who accept the certificate. /usr/bin/openssl req -new -key /etc/pki/tls/private/localhost.key \ -x509 -days 365 -set_serial $RANDOM \ -extensions v3_req \ -out /etc/pki/tls/certs/localhost.crt However, I have no idea how seriously anyone will take the issue unless there's a broad base of users who request such a change. The situation can be made slightly better by this change, but making it doesn't make self-signed certificates less common. As long as self-signed certificates are common, users will get into the habit of permanently accepting untrusted certs. If they do that, and the cert specifies that it is a CA, then they've installed a new CA. These certs are just a small part of a much larger and more serious design problem with SSL. User agents (especially Firefox) don't really make clear that a new cert is a CA, rather than a certificate with more limited purpose. Users can't really be expected to learn the difference, either. I really hope that the whole trust chain aspect of SSL is thrown away someday soon, replaced by some better model. Convergence.io is one I really like. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] wiping out data on a disk (no physical acess to the machine)
On 01/12/2013 04:33 PM, zGreenfelder wrote: at $long_ago_job we'd use a pxe-netboot image; effectively DBAN (http://www.dban.org/). which only really works if you have another server in the remote location to act as the pxe server. Anything that you can PXE boot, you should also be able to load from GRUB. http://ralintech.blogspot.com/2011/02/remote-wipe-with-dban.html If DBAN features SSH, this would work. I assume that it does, since the blog is specifically about remotely wiping a system. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Off-Topic: Low Power Hardware
On 01/11/2013 06:55 AM, SilverTip257 wrote: I'm in search of some hardware that consumes a low amount of power for use as a test-bed for Linux, various coding projects, and LAN services. I use the Soekris 6501 fairly extensively. It's available in a much smaller than 1U case, or 1U if you prefer: http://soekris.com/net6501.htm However, Supermicro makes some systems that are probably just as good, with two instead of four NICs: http://www.newegg.com/Product/Product.aspx?Item=N82E16816101365 Once you add RAM to the Supermicro, the two are very similar in cost. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] wiping out data on a disk (no physical acess to the machine)
On 01/12/2013 04:35 PM, Reindl Harald wrote: Usually if no service is running dd if=/dev/zero of=/dev/your-sysdisk does crash more or less very late and if you destory the datadisks before there is nearly zero chance to recover any data If I care enough to wipe the disks in a server, usually and late is not going to cut it. Any attempt by the kernel to read any filesystem is likely to cause a panic before wiping is complete. If you want to completely wipe a disk, you need the root filesystem to be somewhere else. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] luks and aes-ni
Hi, Short version: If I had a CPU with the aes-ni [1] feature would luks use it? I know that Upstream Vendors Security Guide [2] says: ...snip The default cipher used for LUKS (refer to cryptsetup --help) is aes-cbc-essiv:sha256 (ESSIV - Encrypted Salt-Sector Initialization Vector). Note that the installation program, Anaconda, uses by default XTS mode (aes-xts-plain64) snap... I also found a notion in the forums that maybe only aes-cbc is using aes-ni [3] and that could mean that after a install aes-ni is not used at all. Does anyone know about this or has experiences? [1] http://en.wikipedia.org/wiki/AES_instruction_set [2] https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-LUKS_Disk_Encryption.html [3] http://forum.centos.org/modules/newbb/viewtopic.php?topic_id=38226forum=56post_id=166657#forumpost166657 -- Kind Regards, Markus Falb signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] evaluating backup systems: rsync
On Fri, Jan 11, 2013 at 10:26 PM, Keith Keller kkel...@wombat.san-francisco.ca.us wrote: On 2013-01-12, SilverTip257 silvertip...@gmail.com wrote: You mentioned about it running with other people changing files ... it works ok for me. I have gigabytes of backups that get rsynced in the early to late morning ... not always are backups completely finished when rsync scans the files. So it picks up on it when the cronjob runs the sync a few hours later. Since rsnapshot uses rsync under the hood, this strategy works for rsnapshot as well. The only real hiccup is if a user deletes a file between when it's scheduled to be synced and when rsync actuall reaches it to sync, rsync might produce a harmless error message. Yep, a harmless error message. *** You may have to run rsync as root with sudo to preserve all permissions/ownership. *** At work we have it locked down in sudoers to do so. It was a setup that predated my employment there, so I don't know if running it as root was necessary. Using SSH keys for auth. You can also use an OpenVPN tunnel and NFS mount with no_root_squash. I like this method a lot because the mount can be made read-only, to ensure that no source data ever gets accidentally clobbered. With an ssh key there's a risk (probably minimal, but nonzero) that a fumblefingers might delete some data on the wrong side. NFS over a VPN tunnel isn't a bad idea -- being able to make the mount read-only can be beneficial. True, a risk is present if one is manually syncing the data. I run my routine/daily rsyncs via a cronjob, so once it's set it is not going to get fumbled. ;) --dry-run is important to test before clobbering. --keith -- kkel...@wombat.san-francisco.ca.us ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos -- ---~~.~~--- Mike // SilverTip257 // ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] wiping out data on a disk (no physical acess to the machine)
On Sat, Jan 12, 2013 at 8:36 PM, Gordon Messmer yiny...@eburg.com wrote: On 01/12/2013 04:33 PM, zGreenfelder wrote: at $long_ago_job we'd use a pxe-netboot image; effectively DBAN (http://www.dban.org/). which only really works if you have another server in the remote location to act as the pxe server. Anything that you can PXE boot, you should also be able to load from GRUB. http://ralintech.blogspot.com/2011/02/remote-wipe-with-dban.html If the OP has a BMC/ILO in his server, he could set the next boot device to a PXE server he controls. Then issue a reboot via serial over LAN and it can boot whatever live Linux image (benefit being SSH is available) and shred from there. DBAN is nice as it is/can be automated, but it may not be a suitable solution for this situation. The OP will not have any SSH access with DBAN nor access to the console (I'm thinking serial over LAN) because DBAN does not likely output to a serial port. If DBAN features SSH, this would work. I assume that it does, since the blog is specifically about remotely wiping a system. To the best of my knowledge DBAN has not had SSH support added. The original/primary developer no longer works on the project. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos -- ---~~.~~--- Mike // SilverTip257 // ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
