Ubuntu Linux

[grey_moon]

Alpha 6 is pretty darn snappy compared to hardy....

Personally I'm waiting for the netbook support for my 901 and also hoping they adopt empathy before it is released

[IRJustman]

Now for the really insane: I'm looking at installing Ubuntu on my recently-decommissioned UltraSPARC-based Ultra 5 workstation! (It'll be an older version as it appears to have been discontinued for sparc64.) It used to be my former job's mailserver which ran Solaris 2.6 and Post.Office. When shop closed, I inherited the machine along with the accounts that machine served (I have since migrated that service over to a FreeBSD machine which holds their websites when one of the machine's hard drives started making really bad bearing noises). Now, it's just an extra machine I have lying around. Right now, it's running FreeBSD/sparc64 7.0-RELEASE.

Has anyone played with Ubuntu on non-x86(-64) hardware? Nowadays, it seems to ONLY be available for x86(-64) machines.

--Ian.

[martino]

What's a good piece of software for editing PDF files?

[Proto]

PDFedit could be what you need.

[Epyon9283]

Originally Posted by IRJustman

Now for the really insane: I'm looking at installing Ubuntu on my recently-decommissioned UltraSPARC-based Ultra 5 workstation! (It'll be an older version as it appears to have been discontinued for sparc64.) It used to be my former job's mailserver which ran Solaris 2.6 and Post.Office. When shop closed, I inherited the machine along with the accounts that machine served (I have since migrated that service over to a FreeBSD machine which holds their websites when one of the machine's hard drives started making really bad bearing noises). Now, it's just an extra machine I have lying around. Right now, it's running FreeBSD/sparc64 7.0-RELEASE.

Has anyone played with Ubuntu on non-x86(-64) hardware? Nowadays, it seems to ONLY be available for x86(-64) machines.

--Ian.

I played with an older version of Ubuntu for PPC on an older iBook. Hardware support was unsurprisingly pretty terrible. The only SPARC machine I have is running Solaris 10.

[IRJustman]

Originally Posted by Proto

PDFedit could be what you need.

Apparently, OpenOffice.org 3.0 which was just recently released will also support editing PDF files.

Originally Posted by Epyon9283

I played with an older version of Ubuntu for PPC on an older iBook. Hardware support was unsurprisingly pretty terrible. The only SPARC machine I have is running Solaris 10.

If I remember properly, OpenSolaris is now being pushed as a substitute for Solaris 10. Curious, is there any real benefit to using Solaris over Linux/FreeBSD/NetBSD/OpenBSD on UltraSPARC? Plus I'd be a bit happier if Sun went with a GPL variant rather than the CDDL (which is partially what keeps ZFS from being developed as a kernel-bound subsystem (the real reason is that Mr. ZFS-on-FUSE apparently doesn't know the first thing about developing kernel drivers), and definitely keeps it from being included in the Linus kernel source tree). If I were to use ZFS on anything, it would not be under Linux; I'd sooner use it on FreeBSD than anything else, including its native Solaris.

--Ian.

[WanderingKnight]

Okay, I upgraded to Intrepid yesterday, and now I'm struggling with KDE 4. I know that if I use it enough I'll get used to it, but there are so many things... so buggy and unstable. It's definitely not mature enough yet.

I miss KDE 3. I wonder why Canonical decided not to support it anymore starting 8.10, considering KDE 4.2 hasn't even been released.

[npal]

KDE4 is good, I tested 4.0, 4.1+ on the Kubuntu versions, but it's still rough around the edges. However, my preference is KDE4->GNOME->>>>>>KDE3. I absolutely hated KDE3. KDE4 IS functional enough for most things, it needs stability fixes and good Amarok 2 and K3b versions. The Kubuntu implementation was good, the Kubuntu Intrepid integration is not that good. I was hoping they'll completely drop KDE3 programs and dependencies, but instead I see Amarok 1.4 installed.

Anyway, I'll check KDE4 again on version 4.2. Right now, I'm still on Ubuntu 8.04.

[WanderingKnight]

KDE 4 is not that different from KDE 3... just a hell lot more annoying in some aspects, and, well, buggy for now.

[martino]

Originally Posted by IRJustman

Apparently, OpenOffice.org 3.0 which was just recently released will also support editing PDF files.

Nice, now only to wait till it makes it into the repositories. Last time I installed something bigger outside of the repository packages I ended up regretting it.

[Ledgem]

I have a question about security on the *NIX systems. Unless you're logged in as root or maybe an administrator account, you'll need an administrator password to modify/remove/install programs and touch core system files. This is generally seen as being a major security benefit for *NIX over traditional Windows systems.

Windows Vista attempted to change that by implementing their User Access Control scheme, which performs the same verification for high-level system access as in *nix's requirement that you type in administrator credentials - the only difference being that for UAC you simply click "allow" or "deny" (or what ever the other option was). One of the early criticisms of UAC was the fact that it would be possible for a program to mimic this window in some fashion to cause harm.

Similarly, for us *nix users, when you type in your login credentials how do you know that it's going straight to the system and isn't being retained by a program for later use? Is there any way to verify (aside from not giving the password and seeing what happens), or are we to blindly trust that the programs we're using either aren't malicious or haven't been maliciously modified?

This doesn't apply specifically to Ubuntu, but this thread has sort of become the Linux/Unix thread in general, so I hope you don't mind my asking this here.

[Slice of Life]

Originally Posted by Ledgem

Similarly, for us *nix users, when you type in your login credentials how do you know that it's going straight to the system and isn't being retained by a program for later use?

Short answer: You don't.
Long answer: Once a hacker has gained root access somehow he can easily install a trojan to fetch the root password as well as the user passwords. It's the duty of the super user to not let that happen in the first place. And any system should run security checkers like tiger to detect anything odd. As long as the hacker doesn't understand and corrupt the security measures fast enough of course.

[Epyon9283]

Originally Posted by IRJustman

If I remember properly, OpenSolaris is now being pushed as a substitute for Solaris 10. Curious, is there any real benefit to using Solaris over Linux/FreeBSD/NetBSD/OpenBSD on UltraSPARC? Plus I'd be a bit happier if Sun went with a GPL variant rather than the CDDL (which is partially what keeps ZFS from being developed as a kernel-bound subsystem (the real reason is that Mr. ZFS-on-FUSE apparently doesn't know the first thing about developing kernel drivers), and definitely keeps it from being included in the Linus kernel source tree). If I were to use ZFS on anything, it would not be under Linux; I'd sooner use it on FreeBSD than anything else, including its native Solaris.

--Ian.

I had installed Solaris 10 on the box before OpenSolaris (or Solaris Express as they were calling their "distribution") was really usable. I needed a "supported" version of Solaris to test some software on. I think in general Solaris offers some benefits over Linux and the BSDs. First and foremost is working ZFS. Solaris also uses SMF instead of the usual init.d scripts. It allows for automatic failure recovery of services and some other cool stuff like starting services in parallel (Linux is getting this now with some of the init systems). I didn't get really deep into Solaris though since all I needed to do was install our software on it.

[SeijiSensei]

Originally Posted by Slice of Life

Short answer: You don't.
Long answer: Once a hacker has gained root access somehow he can easily install a trojan to fetch the root password as well as the user passwords. It's the duty of the super user to not let that happen in the first place. And any system should run security checkers like tiger to detect anything odd. As long as the hacker doesn't understand and corrupt the security measures fast enough of course.

How about trojans that are installed by the users themselves? I could be running a keyboard-grabber as an ordinary user that periodically sends the logs to a website all without violating any permissions.

What I don't know is how SE LInux applies to this. I'll say right now that I routinely set SELINUX to permissive (logs events, doesn't block anything) on RedHat-flavored boxes because it can be a real pain in the neck when enabled. Nevertheless I thought that, when enabled, SE Linux maintains an inventory of legitimate binaries and blocks the execution of ones not in the database. If so, that goes a long way toward preventing the accidental execution of some rogue program as an ordinary user. I may be talking out of my hat here, though.

Just to answer Ledgem's question more generally, there's also the issue of protecting your login credentials when communicating with remote hosts as well. If these are hosts you maintain, you should set up a VPN to encrypt all your traffic between your local network and the remote hosts(s). I like OpenVPN for point-to-point tunnels with shared keys. It's trivial to set up and "just works." I still use SSH within the tunnels; I don't see any performance loss from the double encryption involved.

If you want to comply with official US government standards, you can't use encryption beyond 256-bit AES (pretty secure against everyone except the NSA and similar agencies, I'd guess). You can have keys as long as 448 bits using Blowfish.

[Ledgem]

In the situation I'm imagining, suppose that you're trying to install software. You'll need to enter your administrator credentials to do this. But what if the program actively stores the login and password information and either uses this for a malicious purpose or sends it to a malicious third party. I can't think of a guard against that, aside from using a firewall for the latter concern.

This isn't a question deserving a snooty response of "don't use pirated software, only use legit software from trusted sources" - companies have been compromised on numerous occasions, and it seems to be that it's realistic for source code for some respected program to be modified and unknowingly be distributed. I suppose there's nothing that can be done about that, you're forced to trust that the software is what it is and nothing more. (I except WanderingKnight to remark about how open source software is superior for this concern :P )

Seiji, what do you mean that the government standards dictate that you can't use beyond 256-bit AES - is it illegal to use higher-level encryption?

[SeijiSensei]

Originally Posted by Ledgem

Seiji, what do you mean that the government standards dictate that you can't use beyond 256-bit AES - is it illegal to use higher-level encryption?

I think it depends on the application. If what you're doing has any relationship to the Federal Government, then I think you have to comply with the standard which is some flavor of AES up to 256 bit. One of my clients is a "Community Health Center," which is governed by the Federal "HIPAA" standards for privacy and security of medical information. I use AES256 on my VPN to them to make sure I'm complying with the standard at the maximum level allowed.

For private communications, it probably varies considerably. I'm pretty sure most commercial encryption devices stay within the standard, but if you're rolling your own security I don't think there's any prohibition on the strength of ciphers. OpenVPN uses 448-bit Blowfish by default, for instance.

For organizations like universities which have some ties to the Federal Government, I can't say what the rules might be. If you're working on a Federally-funded project you're probably officially limited to AES. For people involved in research with no Federal ties, only the university's legal department knows the answer.

[Epyon9283]

Originally Posted by SeijiSensei

How about trojans that are installed by the users themselves? I could be running a keyboard-grabber as an ordinary user that periodically sends the logs to a website all without violating any permissions.

What I don't know is how SE LInux applies to this. I'll say right now that I routinely set SELINUX to permissive (logs events, doesn't block anything) on RedHat-flavored boxes because it can be a real pain in the neck when enabled. Nevertheless I thought that, when enabled, SE Linux maintains an inventory of legitimate binaries and blocks the execution of ones not in the database. If so, that goes a long way toward preventing the accidental execution of some rogue program as an ordinary user. I may be talking out of my hat here, though.

SELinux in the stock configuration (at least with the targeted policy) from RH/Fedora wouldn't stop a user from running an executable in their home dir that can make TCP connections to some arbitrary host on the net. You could conceivably create a policy that denies users the ability to run executables in their home directories. You could also write a policy that denies applications the user runs from their home directory from making connections to hosts on the network.

Last I looked, creating SELinux policies was not fun. Not fun at all. There are domains, file labels, types, etc. that you have to deal with.

The default targeted policies in RH/Fedora are mainly there to restrict what daemons may or may not do. There is a policy that can allow/deny samba from sharing home directories, one that allows/denies apache from running cgi, etc. If someone were to compromise a daemon and run code in the daemon's context it should theoretically be limited in what it can do on the system.

[Slice of Life]

Originally Posted by Ledgem

In the situation I'm imagining, suppose that you're trying to install software. You'll need to enter your administrator credentials to do this. But what if the program actively stores the login and password information and either uses this for a malicious purpose or sends it to a malicious third party. I can't think of a guard against that, aside from using a firewall for the latter concern.

This isn't a question deserving a snooty response of "don't use pirated software, only use legit software from trusted sources" - companies have been compromised on numerous occasions, and it seems to be that it's realistic for source code for some respected program to be modified and unknowingly be distributed. I suppose there's nothing that can be done about that, you're forced to trust that the software is what it is and nothing more. (I except WanderingKnight to remark about how open source software is superior for this concern :P )

Open source software is superior for this concern. ^_____________^

You really shouldn't input passwords into closed source applications. But major f...ups also happen with legit open software from most trusted sources. I think I mentioned it already in this very thread. Not long ago there was a major bug in Debian's OpenSSL package (and consequently all Debian derivatives like Ubuntu) making crypto keys vulnerable to brute force attacks. Actually, a tender caress rather than brute force was already sufficient. Not the same as intentionally distributing a Trojan but still ...

Long story short, some noob was maintaining the OpenSSL package, was bothered by some line generating a complier warning, asked the wrong people for help, and IIRC even without revealing that he was working for Debian. And finally, he then changed a second, similar line which introduced the bug that made the keys guessable. And since the code was delivered by DEBIAN nobody seems to have bothered to check it for almost two years.

The morale of this particular case is twofold, I think. 1. Open source doesn't help as long as everybody assumes somebody else will probably have looked into it. 2. Debian doesn't have the manpower to properly maintain their packages and should better trust the developers. I just hope they now have at least two people to check the security relevant code they mess with.

[Utter_iMADNESS]

I have a quick question about using GParted. I recently installed Vista on a 20 GB partition that I made after my Ubuntu partition. But now that I've installed Vista, I've almost completely filled up its partition.
So my question is, can I expand my windows partition without corrupting either partition?
Here's a screenshot of my partitions if it helps:

[Epyon9283]

Originally Posted by Slice of Life

Open source software is superior for this concern. ^_____________^

You really shouldn't input passwords into closed source applications. But major f...ups also happen with legit open software from most trusted sources. I think I mentioned it already in this very thread. Not long ago there was a major bug in Debian's OpenSSL package (and consequently all Debian derivatives like Ubuntu) making crypto keys vulnerable to brute force attacks. Actually, a tender caress rather than brute force was already sufficient. Not the same as intentionally distributing a Trojan but still ...

Long story short, some noob was maintaining the OpenSSL package, was bothered by some line generating a complier warning, asked the wrong people for help, and IIRC even without revealing that he was working for Debian. And finally, he then changed a second, similar line which introduced the bug that made the keys guessable. And since the code was delivered by DEBIAN nobody seems to have bothered to check it for almost two years.

You shouldn't put passwords into closed source apps? Zuh? Just being open source doesn't mean the code for an app has been reviewed at all by anyone. You could go to sourceforge, download an app you think sounds awesome but was written by a single person and not sufficiently reviewed by anyone. You could also download a closed source app from a no-name software company and get code that wasn't adequately reviewed. In either case the application could be stealing passwords. Unless you review the code yourself you can't be sure that any application on your system isn't doing something malicious.

Someone who didn't understand the OpenSSL code they were changing broke OpenSSL in Debian. He asked on an OpenSSL mailing list before making the change and the two substantive responses received said it was fine to make the change he was asking about. He provided almost no context though so it was possible they didn't realize where in the source tree he was making the change. Then the flaw was allowed to exist for almost two years because Debian maintains their own OpenSSL patch set. This is another mistake IMO. Any patches a distro develops (that aren't specific to getting the package compiling/running on the particular distro) should attempt to be pushed upstream. If they had done that someone from OpenSSL may have figured out that this patch would introduce a big problem.