The Linux Questions Thread: a bunch of pitfalls, but technically it's possible

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Linux Questions Thread: a bunch of pitfalls, but technically it's possible

ColdPie: Jun 9, 2006

Oh man, 30+ pages. Sorry if this has been asked, but I figure it's a pretty easy question in any case.

I'd like to make a headless Linux (or, hell, any UNIX) box that acts as a small fileserver. What I'm looking for in it most is acting as a CVS server to store my source files. I've already got the hardware, but I'd like a suggestion for a distro.

I know my way around a command line and as the box will be headless anyway, I don't need a GUI. When I need to do maintenance, I'll just use PUTTY. Like I said, the main purpose of this box is to do run a CVS server daemon all the time, I'm not going to be using it for much of anything else.

Does anyone have any distro suggestions?

Edit: I'll be doing most things on a local network, but I would like CVS (and possibly a shell) available outside as well.

# ¿ Aug 3, 2007 01:08

Adbot: ADBOT LOVES YOU

# ¿ Apr 27, 2024 12:00

ColdPie: Jun 9, 2006

bitprophet posted:

Well, any distro can handle that stuff, obviously, so it really comes down to which distro's package manager you like best, how much distro-specific junk you like or don't like, etc.

Since it's just a server and won't do any desktoppery, I'd personally suggest one of the more stripped-down/non-desktop-oriented distros such as Arch (), Slackware or Debian (Debian may not be "stripped down" as much as the other two but it's still a good choice if you do the server install and not the workstation one).

Thanks for the suggestions! I'll take a look at Arch. I've used Slackware before; it's an option too. I think Debian might be a little higher level than I'm looking for.

Also, and this might be important and I regret not mentioning it earlier, the hardware I'm running this on is old. Pentium 3 old. I think that might rule out Arch as it seems to only support i686 and x86-64, both of which are newer than P3 (if I understand correctly). Are there any really stripped-down Linux distros that'd support such old hardware?

# ¿ Aug 3, 2007 03:54

ColdPie: Jun 9, 2006

teapot posted:

To be fair, Debian Stable in the minimal server configuration is perfectly usable for this purpose.

i686 is everything starting from Pentium Pro. I have Ubuntu 7.04 running on P3 450.

Oh, okay

I guess that's all I needed, then. Thanks for the help!

# ¿ Aug 3, 2007 13:30

ColdPie: Jun 9, 2006

bitprophet posted:

Yea, Teapot beat me to it, but i686 means Pentium Pro and up - I've ran Arch on Pentium IIs and IIIs as well as newer stuff.

Arch vs Debian - Debian has been around longer and has more "extra stuff" in terms of scripts and other support mechanisms for packages, i.e. they heavily modify the Apache setup to enable easy enabling/disabling of individual virtual hosts via command-line scripts/symlinks, stuff like that. However, that means that the environment you end up with is often quite different from the "stock" environment, meaning that if you become used to Debian's niceties and then need to move to e.g. Slackware or something, you might feel kinda lost.

I personally, lately, fall on the side of wanting "pure" versions of upstream packages, so that's why I like Arch. It's also easier to make your own packages (or modified versions of existing packages) on Arch than Debian, if that matters to you at all.

At any rate, either one will serve you well

I read pretty much all of the basic Arch documentation at work today and liked what I saw so I'll be giving that a shot first. Hopefully it does well with whatever kind of hardware is in that PC. Since I'm not doing anything more complicated than a command line, though, I figure it'll be fine.

Thanks again for the suggestions.

# ¿ Aug 4, 2007 00:26

ColdPie: Jun 9, 2006

Wow, Arch is pretty awesome. I got the box almost completely set up in about 5 hours between last night and this morning. It's got sshd, an FTP daemon, svnserve, all up and running nicely. This is the easiest Linux install I've ever done

May be in part to it being such a simple setup in the first place, but I really like the way Arch does things.

# ¿ Aug 4, 2007 17:48

ColdPie: Jun 9, 2006

I'm having trouble with SVN on my new Linux server. It's amazingly slow. It actually took over an hour to commit changes to three very small text files over my local network. Using SVN on the machine itself is no faster.

It actually varies, sometimes it's quick, but 9 times out of 10, it's so slow that you'd think it locked up. I really don't know what's up with it and I'd like to figure it out as SVN is the main reason this server exists.

I'm running Arch Linux (fully updated) and SVN 1.4.4 on an old P3 with a dismal amount of RAM (probably 128MB). If anyone has any ideas how to speed this up to acceptable speeds, please let me know. I'll be happy to provide any more information you need.

Thanks!

Edit: I should have mentioned that using ps while a commit is running shows several svnserve processes running, each with 0% CPU usage.

# ¿ Aug 14, 2007 14:22

ColdPie: Jun 9, 2006

bitprophet posted:

That's pretty strange FWIW I use SVN clients and servers on 2 different Arch machines and it works just fine. No real ideas other than googling around for "slow subversion" or "slow svn", and/or searching for that on bbs.archlinux.org .

The only thing I could find was something about /dev/random being slow, which I would have no idea how to fix

I'd really like to fix this problem as SVN is the only reason this server exists.

I could give CVS a shot, but I've heard SVN is better and I'm more familiar with it anyway.

# ¿ Aug 19, 2007 18:35

ColdPie: Jun 9, 2006

covener posted:

tcp trace and syscall trace should give you a pretty big hint

Having never used these tools, they don't really tell me anything. Maybe you can help sort this out?

Running

code:

[root@bngcvs ~]# strace svn checkout svn://localhost:53690/testproj --username <USERNAME> --password <PASSWORD>

returns a whole bunch of stuff (which I could post here if it's wanted) ending with:

code:

munmap(0xb7ca4000, 4096)                = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(53690), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
read(3, "( success ( 1 2 ( ANONYMOUS ) ( "..., 4096) = 76
write(3, "( 2 ( edit-pipeline svndiff1 abs"..., 82) = 82
read(3, "( success ( ( CRAM-MD5 ) 10:test"..., 4096) = 43
write(3, "( CRAM-MD5 ( ) ) ", 17)       = 17
read(3,

where it hangs. Would it be more useful to run this on the server process instead of the svn client? How would I do that?

# ¿ Aug 19, 2007 19:54

ColdPie: Jun 9, 2006

All right, I've got a quick question that's hopefully pretty simple to answer. I just bought a laptop (Lenovo Thinkpad) which supposedly supports Linux. My question is whether I should install the 64-bit version of the distro I use or the 32-bit version. I've heard 64-bit is better for systems with more RAM, and systems with smaller amounts of RAM should use 32-bit versions. Beyond that, I really don't know which to choose.

A few relevant specs:

Processor: Core 2 Duo
RAM: 1 GB
Video: Intel X3100 965 GMA
HDD: 120 GB 5400 RPM
Distro: Arch Linux

Thanks in advance!

# ¿ Oct 18, 2007 15:09

ColdPie: Jun 9, 2006

Ugh, I'm having a bit of a doozy here tonight. I'm trying to set my SVN server to automatically upload backups of the repositories to an FTP once a day. I spent about an hour wrestling with a stupid 5-line shell script file just to get the FTP program to put a date into a filename. Finally, the script inserts the date in the correct spot and everything is well, except I can't upload the files!

I'm using lftp, and it logs in and connects to the server just fine. When it tries to upload the file, it enters passive mode and sticks at "Opening data connection" saying, "Making data connection..." forever.

After a bit of research, my guess is that the port it's trying to connect across is blocked. Here's my network setup:

[Server] -> [Desktop (Bridged Connection)] -> Router -> Modem

The Desktop's bridged connection looks like this:

code:

#/etc/rc.conf
lo="lo 127.0.0.1"
eth0="eth0 0.0.0.0 promisc"
eth1="eth1 up"
br0="br0 192.168.2.5 netmask 255.255.255.0 broadcast 192.168.0.255"
INTERFACES=(lo eth0 eth1 br0)

code:

#/etc/conf.d/bridges
bridge_br0="eth0 eth1"
BRIDGE_INTERFACES=(br0)

The Desktop can connect to FTP and do file transfers just fine, so it seems to be the breaking point. The server has no problem downloading from anonymous FTP (for software updates, etc.), but uploading doesn't seem to be working.

I have no idea what I can do or where to go from here. Running Arch Linux on both desktop and server. Does anyone have any suggestions?

Thanks.

# ¿ Nov 3, 2007 07:48

ColdPie: Jun 9, 2006

Jesus loving tits is there ANY way to remove middle-click paste across all appliations? This is the single most retarded feature I've ever seen. I'm tired of scrolling in a document, accidently pressing a bit too hard, and not noticing the change. All of a sudden compiler errors! Or my resume suddenly has code in the middle of it from 10 edits ago that I can't really undo now!

I'm ready to do just about anything to make this feature go away and die a horrible death behind a shed.

The only solution I can think of is disabling middle clicking entirely in xorg.conf. Is there a better solution?

# ¿ Jan 27, 2008 21:36

ColdPie: Jun 9, 2006

I've got a question about lftp. I'm using it to upload backup files created by Duplicity to my webhost. I set up a cron job to run the backup program and the upload script nightly. My trouble is that lftp insists on overwriting the files on the server, which is a waste of everyone's bandwidth. I'd rather it only upload if the last modified times are different (or only upload if the file doesn't exist, I'm not exactly sure how Duplicity works). Is this possible to do with lftp? If not, is there another way to upload files from a cron job like this?

# ¿ May 2, 2008 06:15

Adbot: ADBOT LOVES YOU

# ¿ Apr 27, 2024 12:00

ColdPie: Jun 9, 2006

Is there a way to prevent a directory from being stupidly deleted, while having it act like a normal directory in every other regard? rm -rf important/ should fail, while mkdir important/stuff/ and touch important/file should both succeed. Unfortunately, I think this is impossible with standard UNIX permissions, but I feel like there must be some common workaround. Any ideas?

# ¿ Feb 27, 2011 20:01

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Linux Questions Thread: a bunch of pitfalls, but technically it's possible