The Linux Questions Thread, SCO non-infringing version

«‹›386 »

The Something Awful Forums > Discussion > Serious Hardware / Software Crap > The Linux Questions Thread, SCO non-infringing version

JHVH-1: Jun 28, 2002

Experto Crede posted:

And what if I don't want ownership retaining? Sorry, should've been clearer, I want the files from the remote server to be owned by the user copying them in to the local machine, but I definitely want to retain permissions.

I think your options are to not use -a and only set flags you want, or add --no-owner/--no-o --no-g (You can negate most of the flags this way)

JHVH-1 fucked around with this message at May 22, 2013 around 00:36

# ? May 22, 2013 00:31

Adbot: ADBOT LOVES YOU

# ? May 25, 2013 09:13

nitrogen: May 21, 2004; Oh, what's a 217°C difference between friends?

you can run the rsync daemon and have all incoming files for certain "shares" permissions adjusted.

/etc/rsync.conf

code:

[omgshare]                                            
  path = /export/omgshare
  comment = "omg an rsync share"
  use chroot = true              
  uid = settothisuser                     
  gid = settothisgroup
  read only = false
  auth users = nitrogen 
  secrets file = /etc/rsync/omgshare

# ? May 22, 2013 00:40

Misogynist: Jul 14, 2003; hubthumping

Lawen posted:

Oh god have you been spying on my company (still have a few RHEL3 boxes in production )

We've still got RH7.3. Welcome to academia!

On the bright side, if this thing sticks around for another 24 months or so we'll be simultaneously running RH7.3 and RHEL7.3.

# ? May 22, 2013 05:09

evol262: Nov 30, 2010; #!/usr/bin/perl

Saint Darwin posted:

Minor versions are very easy and are just yum upgrade

Major version upgrades are no no no don't try everything will go wrong

To be fair, a lot of things do go wrong, and "we won't support this because you might have accidentally kept libpcre around and left yourself in a situation we can't duplicate when you file a bug" is a reasonable stance. I don't recommend that people do it. On the other hand, I've made my career (to this point) on engineering major RHEL upgrades, and Red Hat Consulting is frequently tasked with helping people through it in a supportable manner.

Lawen posted:

RHEL3 hit end of life February of 2012. RHEL4 EOLed this past Feb. RH sells extended support plans that cover EOLed versions for 1 year after the official EOL date, so as of 2/13 you can't buy support coverage for RHEL3 and as of next Feb, RHEL4 is completely unsupported. I'd think you (IamJacksAlcoholism) could follow the same timeline to stop supporting older RHEL versions for your product.

As a rule, it's "10 years from initial release" until it's out of Production 3. Practically speaking, you probably want to start upgrading once it's out of Production 1 if you possibly can.

# ? May 22, 2013 14:33

keyvin: Sep 9, 2003; My flesh and blood lives. No matter what.

Misogynist posted:

We've still got RH7.3. Welcome to academia!

My network security class used (with all official patches) RH7.3 to learn about remote exploits, shellcode, etc. Fond memories.

# ? May 22, 2013 16:22

Begall: Jul 28, 2008

I've got a problem with mounting a hard drive which is driving me up the wall. Basically, I've got a 2TB NTFS formatted partition. I've added it to fstab, and anything running under my main user account is able to read/write to it. Any other user does not have (at least, maybe read too) write permission. I've read up on this problem, and tried adding some options to fstab to fix this, but my system seems to be totally ignoring the options I've entered:

/etc/fstab:
/dev/sda2 /media/xbmc/F8F41E22F41DE422 ntfs defaults,gid=1000,uid=1000,umask=000 0 0

~$ cat /proc/mounts
/dev/sda2 /media/xbmc/F8F41E22F41DE422 fuseblk rw,nosuid,nodev,noexec,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096 0 0

Any ideas? Thanks.

# ? May 22, 2013 19:48

Megaman: May 8, 2004; Thanks mods, peace. Still, this guy Megaloman is kind of a "special helmets" retard case, no?

Misogynist posted:

We've still got RH7.3. Welcome to academia!

On the bright side, if this thing sticks around for another 24 months or so we'll be simultaneously running RH7.3 and RHEL7.3.

Please tell me what the possible reason this can't be wiped and upgraded to latest is? I can only think of 1 reason and I doubt it applies to any machine you have.

# ? May 22, 2013 19:53

evol262: Nov 30, 2010; #!/usr/bin/perl

Megaman posted:

Please tell me what the possible reason this can't be wiped and upgraded to latest is? I can only think of 1 reason and I doubt it applies to any machine you have.

B-b-b-but no replacement came out for the legacy garbage we're using in the last decade, and p2v is really hard!

# ? May 22, 2013 22:29

contrapants: Mar 9, 2013; dd if=/dev/random of=/dev/kmem bs=1 count=1 seek=$RANDOM

Begall posted:

I've got a problem with mounting a hard drive which is driving me up the wall. Basically, I've got a 2TB NTFS formatted partition. I've added it to fstab, and anything running under my main user account is able to read/write to it. Any other user does not have (at least, maybe read too) write permission. I've read up on this problem, and tried adding some options to fstab to fix this, but my system seems to be totally ignoring the options I've entered:

/etc/fstab:
/dev/sda2 /media/xbmc/F8F41E22F41DE422 ntfs defaults,gid=1000,uid=1000,umask=000 0 0

~$ cat /proc/mounts
/dev/sda2 /media/xbmc/F8F41E22F41DE422 fuseblk rw,nosuid,nodev,noexec,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096 0 0

Any ideas? Thanks.

A few things you can check:

"fuseblk" is File System in Userspace, so mount.ntfs isn't what is mounting the drive. That might be why only the main user can access it; it's mounted after the user logs in.

First, a umask of 000 means no one can read, write, or execute anything, so that makes the drive useless even if it can mount.

Make sure "/media/xbmc/F8F41E22F41DE422" is a directory that already exists when the drive isn't mounted. umount the drive and look at the directory. fstab won't create directories for your mounts, but some daemons e.g. udev will.

Make sure your kernel has NTFS support compiled in.

Make sure you have the NTFS driver installed. The package name is "ntfs-3g" or some variant. I'm not sure, but it might require a fstab line like:

code:

/dev/sda2 /media/xbmc/F8F41E22F41DE422 ntfs-3g defaults 0 0

If that still doesn't work, take a look at dmesg or the end of /var/log/messages for any errors or info about the drive. There might be an error message you can Google.

# ? May 22, 2013 22:58

Varkk: Apr 17, 2004

Megaman posted:

Please tell me what the possible reason this can't be wiped and upgraded to latest is? I can only think of 1 reason and I doubt it applies to any machine you have.

Institutional inertia mostly.

# ? May 22, 2013 23:10

Megaman: May 8, 2004; Thanks mods, peace. Still, this guy Megaloman is kind of a "special helmets" retard case, no?

evol262 posted:

B-b-b-but no replacement came out for the legacy garbage we're using in the last decade, and p2v is really hard!

I have no idea what that first part means, but the second part is dead wrong. P2v is incredibly easy. What legacy garbage are you using that can't be easy dev'd to something else or an updated version of that thing? Also, you do know that you CAN compile old source/specs into an rpm and install it on the new box, right? From a sysadmin point of view there is no excuse to keep an old box, again except for one that I can think of which is hardware ties to licenses, and even then I don't see an excuse, because that means it's either crap software, or stubborn vendors. Vendors are willing to work out deals/work around expensive hardware tied licenses for the amounts of money companies pay for them.

# ? May 22, 2013 23:40

Megaman: May 8, 2004; Thanks mods, peace. Still, this guy Megaloman is kind of a "special helmets" retard case, no?

Varkk posted:

Institutional inertia mostly.

This is the best way of saying "laziness" I've ever heard

# ? May 22, 2013 23:41

fatherdog: Feb 16, 2005; *RONK, RONK*
Make that three rard-boiled eggs.

Megaman posted:

Vendors are willing to work out deals/work around expensive hardware tied licenses for the amounts of money companies pay for them.

You would be surprised at how many times this is not the case.

# ? May 23, 2013 02:15

Megaman: May 8, 2004; Thanks mods, peace. Still, this guy Megaloman is kind of a "special helmets" retard case, no?

fatherdog posted:

You would be surprised at how many times this is not the case.

But as I said before, these is usually a very very small number of machine. Almost no one ties their licenses to hardware, those are usually the most expensive licenses out there. Usually ultra expensive scientific data collectors and whatnot. I came across 1 machine in my 2 years at the GE research center, and the machine actually broke, we didn't even have a chance to migrate it. The vendor let us have one for free and rebound it to a new device. My experience there does not prove all places have 1 machine, but the probability of having several machine at your workplace like this must be very very low. Even so, most people don't deal with licenses like that, if licenses at all.

Megaman fucked around with this message at May 23, 2013 around 02:29

# ? May 23, 2013 02:27

telcoM: Mar 21, 2009

Experto Crede posted:

And what if I don't want ownership retaining? Sorry, should've been clearer, I want the files from the remote server to be owned by the user copying them in to the local machine, but I definitely want to retain permissions.

If you do the copying as a non-root user with no special capabilities, the kernel will force the copies the user creates to be owned by that user. (In a remote copy, that is the user the destination end of the copy operation is running as.)

You can tell rsync/scp to preserve everything, and the ownership still won't be retained, because the tool will not be allowed to set the ownership unless you're running the tool as root (or if your system is configured to use capabilities, the CAP_CHOWN capability is set for the user).

# ? May 23, 2013 04:52

keyvin: Sep 9, 2003; My flesh and blood lives. No matter what.

All this talk about scp has me wondering something. Does it start a shell or source .bashprofile or anything to know the user's umask? Or does it just use a default set of permission. I could probably figure this out through experimentation, but

# ? May 23, 2013 12:42

Lawen: Aug 7, 2000

keyvin posted:

All this talk about scp has me wondering something. Does it start a shell or source .bashprofile or anything to know the user's umask? Or does it just use a default set of permission. I could probably figure this out through experimentation, but

Not positive, but I think it instantiates a non-interactive shell. So it honors umask but doesn't parse .bashprofile for your aliases and custom functions. I'm sure someone will correct me if I'm wrong.

# ? May 23, 2013 13:28

Misogynist: Jul 14, 2003; hubthumping

Megaman posted:

Please tell me what the possible reason this can't be wiped and upgraded to latest is? I can only think of 1 reason and I doubt it applies to any machine you have.

You need somebody willing to actually test and certify that the migration was successful, and so loving many people here will not be bothered to do it. As it stands, we're having a hard enough time just getting them to tell us what the applications are and what they do, forget completely insane things like "after we've copied all this stuff over, how do we know it's actually working?"

This is academia, so there's nobody at the top saying something sane like "just do it already, you lazy shitbag."

Also, most of these applications are hugely interdependent custom mod_perl monstrosities that would be nigh impossible to redeploy on the same box predictably, much less something ten years newer. We can't rely on past experience to assure the user "hey, we're really sure this will work" without them supplying a test plan.

Megaman posted:

This is the best way of saying "laziness" I've ever heard

It's a pretty accurate description of this whole vertical, though. We're not-for-profit, so everybody was underpaid even before federal sequestration and nobody is motivated to give a poo poo. Then there's the turnover issues; nobody besides the director still works here from the time that these things were written.

Misogynist fucked around with this message at May 23, 2013 around 16:18

# ? May 23, 2013 14:35

evol262: Nov 30, 2010; #!/usr/bin/perl

Megaman posted:

I have no idea what that first part means, but the second part is dead wrong. P2v is incredibly easy. What legacy garbage are you using that can't be easy dev'd to something else or an updated version of that thing? Also, you do know that you CAN compile old source/specs into an rpm and install it on the new box, right? From a sysadmin point of view there is no excuse to keep an old box, again except for one that I can think of which is hardware ties to licenses, and even then I don't see an excuse, because that means it's either crap software, or stubborn vendors. Vendors are willing to work out deals/work around expensive hardware tied licenses for the amounts of money companies pay for them.

Man, I thought I missed sarcasm, which the whole comment was.

That said, whoa there. You can compile old source (specfiles that old will almost certainly need to be rewritten from scratch, since so many package names have changed, packages been obsoleted, et al over the last decade), but you probably won't be able to. It's fatuous to say "this software written against glibc 2.2 and gcc 2.x will compile fine on RHEL6!" It probably won't. Then it's a question of whether or not you want to invest development time in porting this thing that keeps looking for function definitions which aren't there in libraries which may not be there in a new system when your RH7.3 box doesn't have those problems.

You can move the application and its libraries along with the requisite version of libc into a directory, chroot it there, and run it, but there's no guarantee that'll even work, since glibc is somewhat tied to the kernel, and depends on features which weren't present until later (2.4.22). It's extremely likely that whatever ABIs glibc 2.2 depended on have been dropped from the kernel or changed so much that you'lll just core.

You should just p2v it, but if you think you can take a 10 year old tarball or RPM specfile and ./configure && make && make install or rpmbuild -bb, you've obviously never done it. Or you were working with the best-written software in the history of man, but even any non-trivial piece of software from 10 years ago is going to depend on libraries which you just can't get running on a new system.

As far as the "hardware licensing isn't an excuse, because it's crap software, or stubborn vendors"? I'd guess that if that's the case, this (academic) company probably paid them peanuts for an academic license 10 years ago and nothing since, so the vendor may not cut them much slack. Ultimately, it's not really your call as a sysadmin.

Megaman posted:

But as I said before, these is usually a very very small number of machine. Almost no one ties their licenses to hardware, those are usually the most expensive licenses out there. Usually ultra expensive scientific data collectors and whatnot. I came across 1 machine in my 2 years at the GE research center, and the machine actually broke, we didn't even have a chance to migrate it. The vendor let us have one for free and rebound it to a new device. My experience there does not prove all places have 1 machine, but the probability of having several machine at your workplace like this must be very very low. Even so, most people don't deal with licenses like that, if licenses at all.

FlexLM is still a thing, especially in academia and research. Windows activation is keyed off hardware (yes, you should have a site license, but not everyone does). Some VMware products call home. You may not deal with licenses, granted, but please don't assert that most people don't. The hardware licenses should be tied to a dongle, but may not be. And "ultra expensive scientific data collectors" are common in academia. Ironically, FlexLM license servers (FlexLM is intended explicitly to provide floating licenses that aren't tied to hardware) are tied to hardware, and losing your FlexLM server can mean days of twiddling your thumbs.

I agree with what you're saying about having almost no reason to have a 7.3 box around, but everything else you're saying is making you look stupid. You should stop.

keyvin posted:

All this talk about scp has me wondering something. Does it start a shell or source .bashprofile or anything to know the user's umask? Or does it just use a default set of permission. I could probably figure this out through experimentation, but

Non-interactive.

# ? May 23, 2013 14:54

eh4: Jul 1, 2009; hi my name is eh4, copypasting articles from shitmedia like crikey is a valid substitute for having actual opinions

evol262 posted:

It misses the point entirely in any case. We already maintain, test, and fight with (sometimes) service definitions on Upstart and systemd. sysvinit is comparatively easy, because it's not parallel at all, but adding support for Debian now means that if we change a script, you're evaluating service dependencies for 3 different init systems. Adding sysvinit support is easy. Feature parity is hard. Testing adds additional work for us for no benefit. Supporting your option limits my options as a package maintainer/developer, and while that's a tradeoff that works sometimes, there's sometimes no benefit to bending over backwards to make sure that the limited subset of users who want to run sysvinit/openrc+syslinux+hand-built-kernel(no initrd, non-standard .config) plus whatever other options you have instead of systemd+grub+distro-kernel are happy. At that point, as said earlier, it's "patches accepted".

Point taken, I live in a Debian world, so I don't have those heterogeneous issues. From a strictly Debian point of view, I don't really see the need for systemd anyway - there's a survey their maintainers are putting out now which will be interesting when it's done.

I'm curious to know why upstart is needed unless you're also supporting Ubuntu systems.

# ? May 23, 2013 23:53

evol262: Nov 30, 2010; #!/usr/bin/perl

eh4 posted:

Point taken, I live in a Debian world, so I don't have those heterogeneous issues. From a strictly Debian point of view, I don't really see the need for systemd anyway - there's a survey their maintainers are putting out now which will be interesting when it's done.

I'm curious to know why upstart is needed unless you're also supporting Ubuntu systems.

Systemd isn't strictly necessary, but it's nice to have parallelism. There's almost an order of magnitude difference between the startup times of Fedora and RHEL5, purely due to parallelism. Having it picked up by so many core projects gives it an edge up. I realize that it'll be fragmented for a while, but eventual systemd standardization (over openrc, upstart, launchd, SMF, and other competing systems) is promising.

I'm one of the developers for RHEV/oVirt, and targeting RHEL/CentOS6 means targeting Upstart. We'd love to support Debian as well (once VDSM support on Debian is better) and Gentoo (same), though supporting different init systems is going to make it a big of a headache. We've supported SysV in the past (on RHEL5), and I wasn't sorry to see it go, but that's life.

# ? May 24, 2013 00:48

ExcessBLarg!: Aug 31, 2001

evol262 posted:

Systemd isn't strictly necessary, but it's nice to have parallelism.

Debian's sysvinit-utils uses startpar to start init.d scripts in parallel. The dependencies are determined from the LSB "INIT INFO" header.

evol262 posted:

We've supported SysV in the past (on RHEL5), and I wasn't sorry to see it go, but that's life.

I recall it's pretty awful on RHEL due to the lack of start-stop-daemon. Hell, I installed dpkg on a RHEL machine once just to get start-stop-daemon.

# ? May 24, 2013 04:55

Adbot: ADBOT LOVES YOU

# ? May 25, 2013 09:13

evol262: Nov 30, 2010; #!/usr/bin/perl

ExcessBLarg! posted:

Debian's sysvinit-utils uses startpar to start init.d scripts in parallel. The dependencies are determined from the LSB "INIT INFO" header.

I wasn't aware of that. It's a nice enhancement to SysV, though still doesn't cover nearly all of the use cases of systemd.

ExcessBLarg! posted:

I recall it's pretty awful on RHEL due to the lack of start-stop-daemon. Hell, I installed dpkg on a RHEL machine once just to get start-stop-daemon.

It's awful on RHEL because it's SysV, and no amount of hacks will make it less awful. I install chkconfig on Debian systems, but that doesn't make it the right thing to do. Sourcing /etc/init.d/functions in any of your scripts on RHEL would serve the same purpose.

# ? May 24, 2013 13:34

«‹›386 »

The Something Awful Forums > Discussion > Serious Hardware / Software Crap > The Linux Questions Thread, SCO non-infringing version